Preface

Last edited: 10/25/2017 7:30:30 AM

Welcome to the Redbex Reference Manual. Redbex is a software system that brings extensive functionality and has huge potential for enhancing and optimizing the way you store mange and evaluate data resulting from the observation of natural phenomena. Designed from scratch to be a generic and flexible solution for many real world sensor data management problems, Redbex builds on universal concepts, standards and work flows that allow to use the product in many different application areas.

This Reference Manual is a detailed reference for Redbex. It provides insight on how Redbex works and what functionality it provides to the user. This manual will give you all the information you need to unleash the full power of Redbex and to use the software it in an effective and creative way.

The price of the generic approach and the flexibility of Redbex is, that to use the product to its full potential, you should have at least basic knowledge of the fundamental concepts. Therefore this Reference Manual provides deep insights and contains information for first time users as well as power users and system administrators.

This Reference Manual was published on 2018-05-14 08:35. The contents of this Reference Manual are constantly updated and refer to the latest version Redbex. To get the latest version or other formats of this Reference Manual visit www.redbex.com.

Figure 1: Redbex provides mighty tools for expert data analysis. This is a screenshot of the Redbex Smart Client showing a contour line map of the ground water table.


Intended audience

Last edited: 10/5/2017 11:51:26 AM

This Reference Manual covers all aspects of the Redbex software system. It includes information for the occasional system user, power users, administrators but also for third party developers and decision makers. It is not intended to be a step-by-step guide that shows you how to solve a particular sensor data management problem, but gives you the knowledge that enable you to use Redbex in a way that fits best to your requirements.

This Reference Manual does not require any prior knowledge of Redbex but a good general understanding of IT systems is surely necessary.


Typographic conventions

Last edited: 10/5/2017 11:51:44 AM

The following typographic conventions are used in this Reference Manual.

Subheading (Level 1)

Longer chapters can be structured using subheadings. This text is written beneath a level 1 sub heading 'Subheading (Level 1)'

Subheading (Level 2)

2nd level subheadings can also be used to structure longer chapters.

Terms

When we introduce a new term we put that term in italic letters to distinguish the term from the surrounding text. If the usage of the term in the rest of the chapter is unambiguous only the first occurrence of the term will be put in italic letters.

This is an example term.

Captions and references

Figures, tables, code listings etc have a caption. Captions within one chapter are numbered sequentially and when the chapter text refers to a figure the number of the figure is used. E.g. for details see figure 1.

If figures contain numbered annotations we refer to these annotation like Figure 1:1. In Figure 1 you see two numbered annotations.

Figure 1: This is the caption to an image

User provided data

Whenever we give examples of data the user specifies, this date is shown in a mono-space font like: the data you type

Do distinguish user provided text from punctuation following it punctuations after user provided text are separated by a blank, as you can see in the following example:

The following text is an an example text provided by the user: example 1 . The point is not part of the example.

In many case we use variables in these texts e.g. <firstname>, <lastname> the text in <> should then be replaced by the text you provide.

Keyboard shortcuts

Carets and special formatting are used to identify keys on the keyboard E.g. Hit <Del> to delete the entry.

Mathematical formulas

Simple mathematical formulas are formatted like this: a^2 + b^2 = c^2 .

Code listings

For longer formulas or algorithms we use separate listing blocks like shown in Listing 1.

For longer formulas

pseudo algorithms

or

listings of code, text files etc.

we use code listing formatting.

Listing 1: Code listings always have a caption, in text we refer to the number of the listing.

Important information

Note: Important information is specially highlighted by this formatting, it is only used when we think that the enclosed text is really important for understanding how the system works or for preventing problems with the system.

References to user interface elements

When documenting graphic user interfaces (GUI) we often refer to elements on that graphical user interface. To distinguish the name of the graphical element from the text the element the name is shown like this: GUI element.


Getting help

Last edited: 10/5/2017 11:51:10 AM

This manual is one of the main resources for information about Redbex. Additional help resources can be found on the product website at www.redbex.com including training videos and the Redbex Blog.

The latest version of this manual is available online at doc.redbex.com. The latest PDF and CHM versions of this manual can be downloaded from the product website.

Please address comments and questions concerning this Reference Manual and Redbex in general to the Redbex support team.


Disclaimer

Last edited: 10/5/2017 11:51:14 AM

Due to continued product development, information in this Reference Manual can change without notice.

While every precaution has been taken in the preparation of this Reference Manual , Pöyry Infra GmbH does not warrant that this document is error-free, the publisher and the authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. If you find any errors in this Reference Manual, please report them to the Redbex support.


Support

Last edited: 10/5/2017 11:51:42 AM

Support for Redbex is available from:

Webpage : www.redbex.com

Email: support@redbex.com


The name

Last edited: 10/5/2017 11:51:02 AM

Finding a name for a product is nowadays an art by itself. Legal issues, marketing issues, and emotional issues play an important role in the decision process. Finding a name for this product - that was originally developed under the code name Fusion - was no different. After a long thought period we decided for the name Redbex.

Redbex is a portmanteau word formed from red and ibex and refers to the alpine ibex that is on the list of endangered species (the red list). After being extinct for many years the alpine ibex was reintroduced in the Hohe Tauern (the mountain region near Salzburg) around 1970.

The ibex is an excellent climber, its ability to move through rocky terrain fast but seemingly effortless is stunning. Redbex tries to move as elegantly in the rocky terrain of data management as the ibex does in the rocky terrain of the Alps.


Copyright notice

Last edited: 10/5/2017 11:51:12 AM

Copyright of this Reference Manual © 2012-2018 Pöyry Infra GmbH. All rights reserved. Redbex is a registered trademark or trademark of Pöyry Infra GmbH,in the European Union and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.

The Reference Manual contains proprietary information of Pöyry Infra GmbH. It is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the Reference Manual (if published electronically) and the software it describes is prohibited. Please also read the end user license agreement for full details.

The information and intellectual property contained herein is confidential between Pöyry Infra GmbH and the client and remains the exclusive property of Pöyry Infra GmbH. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise without the prior written permission of Pöyry Infra GmbH. If delivered electronically, licensed users are granted the right to print a hardcopy of this reference manual, but may not sell, distribute or otherwise dispose of the hardcopy without written consent of Pöyry Infra GmbH.


Introduction

Last edited: 10/5/2017 11:51:26 AM

Redbex is an extensible general purpose software system for sustainable data integration and analysis with a focus on data generated by sensors. It allows for centralized data handling, expert data analysis and gaining of new information. The generic framework of Redbex makes it possible to provide domain specific add-ons dealing with various disciplines of civil and energy engineering etc. It is designed to be a tool for decision making, project control and cost optimization.

We know the previous paragraph describes Redbex as the Swiss Army Knife of data management software, and we actually mean it. The framework, i.e. the core structure of the software, is extremely versatile and builds on the experience of many years of software development in the area of data management. It integrates concepts that are useful for many data management problems, it is extremely modular and can therefore be easily extended (even by you!).

Not only does Redbex provide a generic framework but it also ships with specialized add-ons that allow you to use the power of the generic framework with the comfort of an expert software that is tailored to the specific needs of your application domain.


Phenomena, features, sensors etc.

Last edited: 10/5/2017 11:51:30 AM

In order to cover a broad range of application areas and to make Redbex as universal as possible the software system is built on strong generic concepts that originate in the Sensor Web Enablement (SWE) standards issued by the Open Geospatial Consortium (OGC).

Redbex deals with recording, structuring, processing and presenting data that originates from natural phenomena. The digital representation of a natural phenomenon within Redbex is accomplished using features. The phenomenon's characteristics at a specific point in time are observed and stored in Redbex as observations of features. Devices used to observe a phenomenon's state are sensors.

Redbex does not limit the types of phenomena that can be managed, and allows easy integration of new types of phenomena. The actual data stored with features and observations is defined by the type of the feature and can range from simple numerical values to complex data structures.

Figure 1: Interaction between Phenomena, Sensors, Observations and Features.

Example 1: A real world phenomenon is the movement of a house (e.g. during construction works of a tunnel). This phenomenon will usually be monitored by some kind of sensor that observes the movement of a specific point of the house. In Redbex the specific point of the house observed by the sensor would be represented by a feature. The results of the observation done with the sensor would then be stored as observations for that feature. From this data Redbex can then calculate settlement, movement directions etc.

Example 2: A real world phenomenon is the turbidity of water at a specific sampling point, this phenomenon might be observed by hydrologists in course of an environmental monitoring program. The result of an observation would be a specific value out of a predefined vocabulary like no turbidity, light turbidity, medium turbidity, heavy turbidity. In Redbex the turbidity at that specific sampling point would be a feature, the results of the investigations done by the hydrologist (usually more than one over time) would be stored as observations.

Example 3: A real world phenomenon is the opinion of people on some political development. This phenomenon might get observed by conducting interviews with randomly selected persons. One interview usually consists of many questions, the answers to this questions are the result of an observation. In Redbex the opinion on the political development would be the feature, each conducted interview would be an observation.

The data that shall be stored for the feature in example 1 might also contain a location of the measurement point, some pictures of the house, a link to a cadastral register (somewhere on the internet) etc. Fore each observation in example 1 the data stored would be the date of the observation and the settlement (a numeric value in some unit). In example 2 the stored data for feature and observation would be totally different. The ability to handle different feature types and observations in one system is one of the key benefits of Redbex.


More formal

Last edited: 10/5/2017 11:51:30 AM

Phenomena are characteristics of real world objects, the value for which may be estimated by application of some procedure in an observation. Note that the phenomena can be “real world” phenomena but also phenomena in "hypothetical worlds" like in simulations.

Whenever we record or process data of a phenomenon in order to describe the phenomenon, this data will only be an abstraction of the "real world". E.g. if the phenomenon we are interested in is the temperature of some fluid we will usually use some kind of thermometer to measure this temperature. Even if the thermometer was indefinitely precise it would still only measure the temperature of the fluid only at one point and would not represent the real world phenomenon exactly. The abstraction of a real world phenomenon that we deal with in Redbex is done using features.

Different kinds of phenomena result in different kinds of features these kinds of features are called feature types. The feature type defines its set of properties that are used to describe features of this type.

An Observation is the act of observing a phenomenon, with the goal of producing an estimate of the value of the phenomenon at a specific point in time. An observation is a specialized event whose result is called an observation result. The observation result is a set of properties that are defined by the feature type of the feature the observation is done fore. Note that we use the term observation for both, the act of observation, and the observation result. Since Redbex deals with observation results the term observation is usually unambiguous.

An entity capable of observing a phenomenon and returning an observed value is called a sensor. We speak of a sensor as a source that produces a value within a well-defined value space of an observed phenomenon. Note that a sensor can be some device as well as a human being.

To observe different kinds of phenomena different kinds of sensors are used, these different kinds are called sensor types. A sensor type defines a set of properties that describe sensor characteristics which do not change over time, a set of properties that describe characteristic of a sensor that is valid for specific time spans and a set of properties that describe characteristics of a sensor that change which each observation.

These very abstract definitions of phenomena, features, observations and sensors are key concepts within Redbex. The generic implementation of Redbex based on these abstract definitions is the key to the flexibility and broad applicability of Redbex.


Physical system structure

Last edited: 10/5/2017 11:51:30 AM

Redbex is a multi-tier system, i.e. it consists of different software parts (tiers) that work together to form the overall software system. The main tiers are the Application Server Database, the Application Server and the Smart Client. Figure 1 shows the main tiers of the Redbex software system and the connections between them.

The tiers can be installed on a single computer or on different computers connected by a network (see chapter installation scenarios for more details). The multi-tier architecture gives you high flexibility in the way you install the system, allows for easy scalability and for seamless integration into your existing IT environment.

Figure 1: Example installation scenario showing all tiers of Redbex and their interconnection

Application Server Database

This is the place where most of the valuable data is stored, it is an obligatory part in every installation scenario. The Application Server Database is a relational database that is designed to run on Microsoft SQL-Server 2008 R2 or higher (any edition).

Application Server

The Application Server is the central place where all the logic of the software system resides and all the data processing occurs. Every client software (like the Smart Client) that wants to store, process or present data connects to the Application Server and uses the services provided. The Application Server is an obligatory part in every installation scenario. It is the only tier that directly connects to the Application Server Database and reads and writes data from/to the database.

Since a lot of processing done on this tier it is also the place where a lot of processing power is needed. Being the portal to all data and services of Redbex, the Application Server is also managing the information security of the system.

The Application Server is accessed by client software (like the Smart Client) through an Application Programming Interface (API) that is based on Windows Communication Foundation (WCF). You can therefore access the Application Server with your custom software over HTTP using standardized Web Service Interfaces.

Smart Client

The Smart Client is a full featured user interface from which all the services provided by the Application Server can be used. At least one installation of the Smart Client is required in every installation scenario. The Smart Client does very little data processing by itself, as it is merely the tier that presents data and takes user input. The Smart Client is also the command & control center for the Application Server.


Application Server

Last edited: 10/25/2017 8:06:40 AM

The Application Server is the heart of Redbex. All of the crucial business logic is handled in this tier and therefore the overall system functionality and behaviour is defined by the Application Server. The Application Server provides services that clients (like the Smart Client, or other software systems) can use.

The following chapters introduce the basic concepts behind the Application Server and explain how things work in the Application Server. It helps to understand how data is handled by the Application Server and therefore gives deep insight into how Redbex works.

Figure 1 shows the logical structure of the Application Server. The Application Server's functionality can be divided in four logical layers: Content, Structure, Processing and Presentation where the higher layers build on the data and functionality of the lower layers. All of these four layers make use of Common Services that provide a common infrastructure to the layers.

The basic data on which the system operates is the content; this is the valuable data that you store within the system. The structure layer contains the methods the system provides for organizing the content. The processing layer transforms data, does calculations and optionally also persists the result as new content. The presentation layer presents content and processed content in a visual way that allows for easy interpretation of data.

Figure 1: Logical structure of the Application Server


%TEXT%

Navigation: Application Server >

Content

Last edited: 10/5/2017 11:51:12 AM

The content is the data provided by the users of the system that Redbex stores and works on. It is the valuable content of your installation of the system.


Features

Last edited: 10/5/2017 11:51:18 AM

In Redbex real world phenomenons are abstracted using features. One real world phenomenon may be abstracted into one or many features in Redbex. E.g. the ground water table in a specific area may be abstracted in Redbex using one or more features of type Ground water level.

Features are the main entities in Redbex holding most of the valuable data stored in the system.


Feature types

Navigation: Application Server > Content > Features >

Feature type

Last edited: 11/8/2017 9:31:50 AM

Feature types are the basic templates that define which properties are used to describe a feature, how this feature can be connected to other features and other things more. The feature type defines the property structures for the feature's type specific data and for the type specific data of the feature's observations.

Each feature is of a specific feature type. The feature type of a feature is defined when the feature is created and immutable thereafter. The Application Server provides a list of predefined feature types that can be used. For each feature type the Application Server provides a specific icon that can be utilized by clients to visually distinguish features of different type.

Feature types are modular. i.e. new feature types can be installed easily when published by Pöyry Infra GmbH. However feature types can only be used if the installed license allows it. The user cannot create his own feature types. Feature types are deployed via the Distribution Server.


Feature data

Last edited: 3/12/2018 12:18:54 PM

Besides the common data that can be stored for every feature, the data that can be stored for a feature of a specific feature type is defined by the feature type. The data that can be stored for a feature can be logically divided into the parts listed in table 1.

Data part

Description

Base data

Base data is data that can be or must be specified for each feature disregarding the feature type. Following data is part of a feature's base data:

·Unique Feature ID (an integerassigned by the Application Server). The unique feature ID cannot be changed once the feature is created.

·Feature GUID a globally unique id for a feature. Can be assigned when a feature is created or will be automatically set by the Application Server when the feature is created.

·Assignment to a domain. The assignment cannot be changed once the feature is created.

·Name of the feature.

·Textual description of the feature,

·Specification of the feature subtype

·Approval information

Spatial data

Data that specifies the location, shape and orientation of the feature. If spatial data can be stored for a feature and what type of spatial systems can be used is defined by the feature type.

The actual spatial reference system on which a feature's spatial data is based is usually defined when a feature is created, and can be changed afterwards.

Type specific data

Each feature type can define type specific data that can be stored with each feature of that type.Type specific data is an instance of a property structure defined by the feature type.

Not all feature types define a property structure for type specific data, i.e. hot all features have type specific data.

Calculation configuration data

If a feature is a calculated feature, the calculation algorithm and other settings that specify the calculation are stored with the feature.

Connector configuration data

If the feature's data source is set to connector the connector configuration data is used to define where the data is read from and might provide additional settings depending on the chosen connector type.

Relations

If a feature is of a type of class platform, group or network it can store relations to its member features.

Configuration data

Data that configures the internal handling of the feature by the Application server and does not describe natural characteristics of the described phenomenon.

Among others this is:

·Date of last modification

·Date of creation

Table 1: Data stored for a feature


Feature type class

Last edited: 12/21/2017 10:41:20 AM

There are several different classes of feature types, each feature type is always associated with one specific feature type class, Table 1 gives an overview of these classes.

If a feature is of a feature type that is of a specific class we say that the feature is a feature of this class. A feature that is of a specific class is referred to as <Class> feature. E.g. A feature that is of a feature type that is of feature type class class platform is referred to as a platform feature.

Feature type class | Description
Regular | Regular feature types with no special functionality.
Group | Group features can contain other features. A feature can be contained in any number of groups. The feature type of the group feature can restrict the feature types it can contain and the number of features of each type that can be contained..
Platform | Platform features can contain other features. A feature can be contained in only one platform feature. The feature type of the platform feature can restrict the feature types it can contain and the number of features of each type that can be contained. Localization of the contained features will be independent of the platform feature.

Table 1: Feature type classes

The general term for group features and platform features is container feature.


Feature data source

Last edited: 10/5/2017 11:51:16 AM

Each feature has a data source that is defined when the feature is created. The data source specifies how and where the observation data of a feature is stored. Table 1 shows the available data sources. The data source of a feature cannot be changed once the feature is created.

Data source | Description
Native | Observation data is stored in the Application Server Database. Observations data can be read and modified
Calculation | Observation data is stored in the Application Server Database. The data cannot be modified but is the result of processing the data of other features using a defined algorithm.
Connector | Observation data is not stored in the Application Server Database but in some external software system. The observation data is read from that system when the user requests it. Redbex supports different types of connectors that are suitable for specific external software systems. Observation data of features with a connector data source cannot be modified.

Table 1: Data source for features


Feature name

Last edited: 11/2/2017 12:52:52 PM

The name is an important characteristic of each feature since the name is shown whenever features are listed and can be used to match external data to features (e.g. during import).

A feature name is a non empty Unicode string a maximum length of 200 characters. When creating or modifying a feature the Application Server will automatically remove leading and trailing white space characters (see table 1) as well as any control character. Control characters are formatting and other non-printing characters, such as ACK, BEL, CR, FF, LF, and VT (Unicode code points from \U0000 to \U001F, \U007F, and from \U0080 to \U009F).

If a feature is member of an identity domain the feature's name must be unique among all features that are member of the same domain.

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).

Table 1: Whitespace characters that are automatically trimmed from the begining and end of a feature name


Aliases

Last edited: 11/13/2017 7:34:52 AM

An Alias is an alternate name for a feature. Each feature in Redbex has a feature name that is intended to identify a feature. However since Redbex usually manages features coming from different source it may well be that a feature has multiple names, e.g. a building might have a official id in the land-register but may additionally have a local (more human readable) name.

The circumstances in which a feature is known under an alias is modeled as Alias Scheme in Redbex. In the example above the alias scheme would be called Local name .


Alias scheme

Last edited: 11/13/2017 8:15:40 AM

An alias scheme is a set of aliases for features, aliases within an alias scheme must be unique and one feature can only have one alias name in an alias scheme. You can think of the alias scheme as the circumstances in which a set of features have an alias, an alias scheme could therefore for example be named Old name, Local name etc.

Alias schemes are associated with domains. You can create any number of alias schemes in a domain. Alias schemes are propagated downwards in the domain tree.

For creating, modifying and deleting an alias scheme the user must have the domain permission Manage alias schemes (7) permission on the domain the alias scheme is associated with. To display an alias scheme and its aliases the domain permission Read (0).

Deleting an alias scheme will also remove all aliases associated with that scheme.


Alias

Last edited: 11/13/2017 7:39:20 AM

An Alias for a feature is an alternate name for this feature that is defined within an alias scheme. Within an alias scheme aliases must be unique, i.e. no two features can have the same alias within the same alias scheme.

As feature names the aliases have a maximum length of 200 characters.

To add, modify or delete an alias you must have the feature permission Modify (1). Note that if an alias scheme is deleted all the aliases in the scheme are also deleted, therefore users with the domain permission Manage alias schemes (7) can delete aliases if the whole alias scheme is deleted.


Feature subtype

Last edited: 10/5/2017 11:51:16 AM

You can define subtypes for feature types that allow you to classify features and to set specific options for all features of the same subtype. Subtypes are linked to domains and therefore a specific subtype is only available for a feature if the subtype is defined in the domain of the feature or any of its parent domains.

Feature subtypes allow you to classify features. They are mainly used to apply settings like default values or property validations to sets of features through feature settings, and to group features for several operations.

Setting a subtype for a feature is optional.


Feature locking

Last edited: 10/5/2017 11:51:16 AM

In order to provide data integrity when accessing feature and observation data, the Application Server may have to lock feature and/or observation temporarily against modification.

There are different lock types the Application Server might use simultaneously on the same feature, table 1 lists these lock types. The modification locks can be shared or exclusive. Shared modification locks can be applied to the same feature by several processes at the same time, shared locks will hinder all processes to modify the data protected by the lock. Exclusive locks can only be applied to a feature by one process, and only if the feature has no other locks applied. Other processes will not be able to apply a (shared or exclusive) lock on a feature as long as it is exclusively locked by one process. The process that applied the exclusive lock can still modify the feature's data or its observation data.

The Application Server allows to query the locking status of a specific feature. The locking status tells how many locks of which type are applied to a given feature. For performance reasons it is not possible to determine who (e.g. which execution of a calculated feature) holds a lock on a feature. To query the locking status of a specific feature the querying user must have read rights on that feature.

Lock type | Resulting behaviour
Feature data | This lock will prevent modifications on the feature's base data, calculation data, type specific data and spatial data. The lock will also prevent approval for the feature, deletion of the feature, adding of feature comments.
Observation modification | This lock prevents the modification of existing observations. Note that this lock does not prevent from adding new observations. This lock will also prevent approval all observations, deletion of observations, adding comments to observations and deletion of the feature.
Observation deletion | This lock will prevent existing observations from being deleted and the feature from being deleted.
Observation creation | This lock will prevent the creation of new observations as well as the deletion of the feature.

Table 1: Locks the Application Server can apply on a feature.

The Application Server does not implement any read locks. As an implication of this, it is possible to have dirty reads. E.g. it is possible to read observation data of a calculated feature that is currently executed. This data is then incomplete and possibly inconsistent (or dirty).


Connector Features

Last edited: 10/5/2017 11:51:12 AM

Features with data source connector are for short called connector features. Connector features can build a bridge between the Redbex Application Server and external data sources. Connector features will load data for their observations from a configured external data source when requested by the user.

Connector features are a great way to connect Redbex to other software systems. In contrast to data import the data from the external data sources is never stored within the Application Server database but always read from the external data source when needed (however some caching might occur to limit loading times).

Which external data sources can be connected depends on the connector types available for a specific feature type. Connector types are deployed by Pöyry Infra GmbH they include all the logic needed to contact an external data source and read data from the data source. Pöyry Infra GmbH provides connector types for some of our own software systems like a specialized TBM Data Analysis Database, most connector types however are developed specifically for our customers. If you need a connector to a specific external data source please contact the Redbex support team.

Note that when connecting external data sources via the internet it must be secured that the communication channel the Application Server uses to contact the data source is not blocked by firewalls, system permissions etc.

Since the Application Server queries data from external data sources at that point in time when the user requests it external data sources must guarantee that they can answer the requests within a specific time span. Since external data sources are not under the control of the Redbex or Pöyry Infra GmbH it is up to the user to configure external data sources in a way that they can answer requests within the time limit.

Figure 1 The the installation structure of the Redbex system when using connector features with external data sources.


Observations

Last edited: 10/5/2017 11:51:30 AM

When a sensor observes a real world phenomenon (that is represented as a feature within Redbex) at a specific point in time the result of this observation is some data that is connected to the feature.

In Redbex we simply use the term observation for observation results, it should be clear form the context when observation means the actual result of an observation or the act of observing.


Observation data

Last edited: 11/8/2017 9:31:52 AM

The data stored for each observation can be divided into logical parts listed in table 1.

Data part | Description
Identification data |
Base data | Data that can be or must be stored with each observation: ·The unique ID of the observation (assigned by the system) ·Sampling timestamp ·Result timestamp ·Sensor used to conduct the observation ·Approval information ·Erroneous flag ·Observation number
Type specific data | Each feature type can define type specific data that can be stored with each observation of features of that type.Type specific observation data is an instance of a property structure defined by the feature type.
Sensor configuration | The instance of a Sensor observation PS defined by the sensor type used for the observation. Sensor configuration data is optional.
Spatial data | The location of the observation in a system defined as observation location system by the feature type of the feature the observation belongs to.

Table 1: Data stored for observations

Each observation stores two different timestamps the sampling timestamp and the result timestamp. The sampling timestamp is the time that the result applies to the feature. The result timestamp is the time when the procedure associated with the observation act was applied. For some observations these are identical, in which case the result timestamp may be omitted. However, there are cases where they differ. The Sampling Timestamp is mandatory for each observation.

Observations are uniquely identified by the feature they belong to and the sampling timestamp. It is not possible to store two observations with the same sampling timestamp for the same feature. The result timestamp is not necessarily unique for all the observations belonging to one feature.

The erroneous flag stored within the observations base data is used to store data that is known to be erroneous but to also be able to exclude this data from processing or presentation. In processing and presentation the Application Server provides filters to omit or include erroneous observations.

The observation number is a user defined number for the observation. Redbex does not ensure that this number is unique however it supports a suggestion mechanism for these observation numbers.

For internal use the Application Server stores the timestamp when the observation was created (first stored in the Application Server Database) and the timestamp when the observation was last modified (when the data for the observation has changed).


Zero reading

Last edited: 10/5/2017 11:51:46 AM

Many feature types define a Boolean zero reading property for the observation property structure.

Observations marked as zero readings are observations where the observer assumes that the sensor or the observed phenomenon changed so that the observed values are not comparable to the last observed values. I.e. the observer assumes that the change in values between the observation prior to the zero reading and the zero reading observation is not necessarily representing the change in the characteristics of the natural phenomenon.


Observation filter

Last edited: 10/5/2017 11:51:30 AM

An observation filter is a generic filter that is used in many places where observations are processed. An observation filter can filter observations different characteristics. Table 1 describes the available filter options in more detail.

Characteristic | Description
Deleted observations | Available options: ·Only not deleted: Only not deleted observations will pass the filter ·Only deleted: Only deleted observations will pass the filter ·Deleted and not deleted: The deleted flag is not checked and deleted as well as non deleted observations will pass the filter
Erroneous observations | ·Only not erroneous: Only observations not marked as erroneous will pass the filter ·Only erroneous: Only observations marked as erroneous will pass the filter ·Erroneous and not erroneous: The erroneous flag is not checked and erroneous as well as not erroneous observations will pass the filter
Included approval status | This filter allows to select a set of approval status. Only observations that are in one of the selected status will pass the filter.
Time filter | The time filter can be a dynamic or static time filter. Observations whose Sampling timestamp is in the selected times span will pass the filter
Axis filter | Allows the definition of a dynamic or static axis filter. This filter criteria only applies to features of a type that has spatial support on observations and that use an axis reference system for observation LSO.

Table 1: Characteristics that can be used to filter observations with an observation filter.


Sensors

Last edited: 10/5/2017 11:51:40 AM

When a phenomenon is observed this is always done with some kind of sensor. Even if the observation is made by a person without using any tool we can still say that this person was the sensor who observed the phenomenon. The result of an observation is nearly always depending on what sensor used and on how that sensor is used, therefore knowing about the used sensor for all your observations is important for interpretation of the observation results.

Each feature type can be observed by different types of sensors delivering observation results of the same structure but having different sensor properties. As features are instances of feature types Sensors are instances of sensor types. Each sensor is assigned to a specific domain. Each observation stored for a feature can be associated with a specific sensor that is in the same or a superior domain as the feature. The Application Server allows to store data for sensor itself, for specific time spans and fore each observation performed with that sensor.


Sensor type

Last edited: 11/8/2017 9:31:52 AM

Sensor types are the basic templates that define which data can be recorded for a sensor of that type and which sensor specific data can be stored for observations done by sensor of that type.

Sensors are always of a specific sensor type. A sensor of a specific type can only observe features of specific feature types. Which sensor type can be used with what feature type is defined by Pöyry Infra GmbH and cannot be changed by the user.

The sensor type defines property structures for type specific sensor data, chronological sensor configuration and observation sensor configuration.

Sensor types are modular. i.e. new sensor types can be installed easily when published by Pöyry Infra GmbH. Sensor types are deployed via the Distribution Server.


Sensor data

Last edited: 11/8/2017 9:31:52 AM

The data stored for each sensor can be divided into logical parts listed in table 1. A sensor is uniquely identified by its numeric sensor ID that is automatically assigned by the system for each created sensor. The Application Server does not check uniqueness of sensor names, it is up to the user to uniquely name sensors id needed.

Data part

Description

Identification data

The unique ID and the name the name and the type of the sensor. Identification data is always available for feature of any feature type

Base data

This description of the sensor, the assignment to a sensor type and to a domain, The base data is available for sensors of any feature type.

Type specific data

A Property structure instance that stores type specific data according to the sensor type of the sensor. I.e. the sensor type defines a property structure and each sensor of that type can then store one instance of that property structure to describe the sensor.

Not all sensor types define a property structure for type specific data. Therefore there may be sensors that do not have type sepecific data.

Chronological sensor configuration

Each sensor may store data that is valid for this sensor in specific time periods. This data is called the chronological sensor configuration.

The chronological sensor configuration includes a property structure instance that stores data according to the sensor type of the sensor.

Table 1: Data stored for a sensor

For most sensor types it is important to know the configuration of a sensor at the sampling timestamp of an observation in order to interpret the observation result. The sensor type defines the property structure that is used to describe the per observation configuration of sensors of that type. Together the data stored for the sensor and the sensor observation configuration describe the configuration of a sensor at the time of a specific observation.

The actual configuration that was in place at the time of an observation sampling is then determined by the Application Server by searching for a chronological sensor configuration entry that covers the sampling timestamp. Figure 1 shows a formal specification of the chronological sensor configuration for a specific sampling timestamp. Note that not all sensor types provide a property structure for chronological sensor configuration.

Figure 1: Specification of the chronological sensor configuration valid for a specific observation sampling timestamp.


Deleting sensors

Last edited: 10/5/2017 11:51:14 AM

Sensors can only be deleted if they are not used as default sensor for some feature and not used in any observation (including deleted observations and observations in deleted features as long as deleted data was not purged).


Configurations for sets of features

Last edited: 11/8/2017 9:26:00 AM

There are several functionalities in Redbex that you usually want to configure for a set of features rather than for each feature separately. In Redbex there are two different concepts that are used to accomplish this: Feature Directives and Feature Configurations.

If a functionality is configured as a feature directive, different configurations of this functionality can apply to one feature at the same time. E.g. multiple observation plans can be configured for the same feature at the same time.

If a functionality is configured as a Feature Configuration only one configuration can exist for one feature at a feature. E.g. there can be only one default value for a property of an observation.

Feature directives
Observation monitoring | Observation monitoring definitions
Observation plans | Definition of observation plans, and reminders
Approval Workflow assignments | Assigns approval workflow templates to features
Feature Configurations
Graphical appearance of features | Defines the graphical appearance of features.
Report template assignments | Dynamically assigns Report templates to features
Feature property structure configuration | Default Values for properties Naming of properties Sequence of property display Grouping of properties Visual appearance of properties Default values for properties Validation rules for properties and collections
Observation Property structure configuration | Default Values for properties Naming of properties Sequence of property display Grouping of properties Visual appearance of properties Default values for properties Validation rules for properties and collections

Table 1: Summary of functionalities configured with feature directives or feature configurations


%Text%

Navigation: Application Server > Content > Configurations for sets of features >

Feature Directives

Last edited: 10/5/2017 11:51:16 AM

Feature Directives is an umbrella term for configurations of functionalities shown in table 1, all these configurations share a common and extremely flexible way how they can be configured for sets of feature by utilizing platform and group relations. Observation Plans are for example configured as feature directives.

Functionality | Feature directive
Observation Monitoring | Observation Monitoring Definition
Approval | Approval Workflow Assignment
Observation Planning | Observation plan

Table 1: Functionalities subsumed under the term Feature Directives

Scope of feature directives

A feature directive is always assigned to a specific feature, however its scope, i.e. the features for which that directive is applicable is defined by the Applicability Rule and the Applicability Filters.

The Applicability Rule defines the applicability of the feature directive using group and platform relations. Table 2 lists the possible settings for the Applicability Rule

All features that result from applying the Applicability Rule are then passed through the applicability filters. The Feature directive will only apply to features that pass each of the Applicability Filters. Table 2 lists the available Applicability Filters.

Enabling or disabling directives

Each feature directive can be active or inactive. Only active directives will be used by the Application Server.

Rule

Effect

This feature

Feature directive will only apply to the feature to which it is assigned.

This feature & members

Feature directive will apply to the feature to which it is assigned and to all member features

Member features are all features that are member of a feature of class group or of class platform (evaluated hierarchically).

If the feature is neither a feature of class group nor of class platform this applicability rule setting equals the This feature setting.

Members only

Feature directive will not apply to the feature to which it is assigned but only to all its member features

Member features are all features that are member of a feature of class group or of class platform (evaluated hierarchically).

If the feature is neither a feature of class group nor of class platform the directive will not apply to any feature.

Table 2: Applicability rule

Applicability Filter | Effect
Feature type | Feature directive will only apply to features that are of the specified feature type. If not set this filter will not limit the applicability.
Feature subtype | Feature directive will only apply to features of a specific type and of a specific subtype of that type. Only subtypes defined in the Domain of the feature to which the Feature Directive is assigned are available.
Name pattern | Feature directive will apply only to features with a name that matches the specified name pattern. The name patten is a simple wildcard pattern.

Table 3: Filter rules available in the applicability filter for Feature Directives


Feature Configurations

Last edited: 11/16/2017 10:02:06 AM

Feature Configurations ins an umbrella term for configurations of functionalities shown in table 1. All these configuration share a common way how they they can be configured for sets of features using a defined Feature/Feature type context (FFT Context). Validation Rules for features are one example of a feature configuration.

An FFT Context is used to define for which features a specific feature configuration is applicable.

An FFT Context can be an explicit or implicit. An explicit FFT Context directly defines the features the configuration applies to. An implicit FFT Context does not define the features it applies to directly but defines characteristics a feature must have so that a configuration applies.

By using implicit FFT Context you can therefore define configurations that will also automatically apply to new or modified features if their characteristics match the FFT Context.

When the Application Server searches for a setting for a specific feature it uses a specific context evaluation logic.

Example: The default value for a property in a property structure is defined within a property structure configuration that is applicable in a specific feature context. If that default value is defined with a feature context of Domain A and feature Type B the default value will be applicable for all features assigned to domain A and feature type B.

FFT Context types

Table 1 lists all types of FFT Contexts supported by the Application Server. Note that each context always implies a feature type i.e. regardless of which context type is chosen the setting will always apply only to features of one specific feature type, i.e. feature settings are always feature type specific.

A feature setting with a context that includes a domain will match for all member features i.e. all features assigned to that domain or any of its sub domains.

Context | Matches
Feature (explicit) | Explicit context. Only for that specific feature. Note that the feature type is of course determined by the feature.
Domain + feature type + feature subtype (implicit) | Implicit context. Matches all features of the specified feature type and specified feature subtype, that are member of the specified domain.
Domain + feature type (implicit) | Implicit context. Matches all features of the specified feature type that are member of the specified domain

Table 1: Feature setting contexts

FFT Context evaluation

Depending on the type of configuration that is associated with the FFT Context, the system uses two different approaches to determine the applicable configurations for a specific feature: the first match or all matches approach.

The first match approach is used whenever only one configuration is needed. E.g. the default value of a property in a property structure can be only one value, there might be different configurations defining different default values with still only one of these settings can be used.

The first match in the first match approach is determined by sorting all settings with matching contexts by their feature setting context specificity. Table 2 lists the contexts from highest specificity to lowest specificity. The first match is the match with the highest specificity.

The all matches approach is used whenever all of the configurations that match the context of the feature can be used. E.g. there can be any number of validation rules for a property in a property structure. When validating a property all validation rules whose context match the current feature's context will be checked.

Context

Feature

Domain + feature type + feature subtype

Domain + feature type

Table 1: Feature contexts ordered by their specificity, highest specificity first


%Text%

Navigation: Application Server > Content >

Associated Data

Last edited: 10/5/2017 11:51:04 AM

Associated data is an umbrella term for Attachments, Comments, Links and Associated features, four different types of data that you can store with every feature and observation irrespective of the feature type.


Attachments

Last edited: 10/5/2017 11:51:04 AM

With Attachments Redbex provides the possibility to add files of any kind to features and observations. Any feature (of any type) and observation can have any number of attachments.

As attachments are files they undergo the same treatment as all other files stored by the Application Server, which includes the generation of preview images and the extraction of meta data.

Besides the file the Application Server stores a Description, a tag and a sequence number for each attachment. The description shall be used to describe the contents of the file, the tag is used for classifying attachments and the sequence number can be used to define the position of the attachment within the set of attachments added to a single feature or observation.


Attachments for features

Last edited: 10/5/2017 11:51:04 AM

To view (download) attachments linked to a specific feature the accessing user must have Read (0) permission on that feature.

To modify (create or delete) attachments linked to a specific feature the accessing user must have Modify (1) permission on that feature.


Attachments for observations

Last edited: 10/5/2017 11:51:04 AM

To view (download) attachments linked to a specific observation the accessing user must have Read observations (3) permission on the feature the observation belongs to.

To modify (create or delete) attachments linked to a specific observation the accessing user must have Modify observations (4) permission on the feature the observation belongs to.


Attachement tagging

Last edited: 10/5/2017 11:51:04 AM

To categorize attachments the Application Sever Supports tagging of attachments. Each attachment can be tagged with one of ten possible tags. The meaning of each of the ten tags can be defined in the context of a feature type in a specific domain. I.e. each of the ten provided tags can be given a name and therefore a meaning for a specific feature type in a specific domain.

Tags are often used in reporting to decide which of the attached pictures shall be shown for a specific feature or observation.


Comments

Last edited: 10/5/2017 11:51:04 AM

A comment is textual information a user adds to a feature or an observation. Each feature and observation can have any number of comments created by different users. Comments are automatically stored with a timestamp when they were created and with a link to the user who created them.

It is not possible to create a comment for another user. Comments cannot be modified, i.e. the comment text, the creation date and the creating user cannot be changed.

A comment can have a maximum length of 4000 characters and is stored as unformatted text.

Comments can only be deleted by users who have the feature permission Manage (7) on the feature they belong to (either directly or through observations). This rule applies to comments created by other users as well as self created comments.


Comments on features

Last edited: 10/5/2017 11:51:10 AM

To read all comments (by any user) linked to a specific feature the accessing user must have Read (0) permission on that feature.

To create a comment for a feature the creating user must have Comment (2) permission on that feature. Comments can be created regardless of the approval status of a feature.

A user can delete all comments on a feature if he has Manage (7) permission on that feature.


Comments on observations

Last edited: 10/5/2017 11:51:10 AM

To read all comments (by any user) linked to a specific observation the accessing user must have Read observations (3) permission on the feature the observation belongs to.

To create a comment for a specific observation the creating user must have Comment Observations (5) permission on the feature the observation belongs to. Comments can be created regardless of the approval status of an observation.

A user can delete all comments on an observation if he has Manage (7) permission on the feature the observation belongs to.


Revoking comments

Last edited: 10/5/2017 11:51:34 AM

For traceability reasons comments can only be deleted if the feature permission Manage (7) is given. However, comments can be can revoked and therefore be marked as invalid, by the user who created it.

Revoking a comment will not delete the comment but will only mark it as revoked. Users reading comments on a feature or observation can still see revoked comments. All users can revoke comments they authored, users with the feature permission Manage (7) on a specific feature can also revoke any feature or observation comment on that feature.

Revoking a comment cannot be undone.


%Text%

Navigation: Application Server > Content > Associated Data >

Links

Last edited: 10/5/2017 11:51:04 AM

Links are URL (Uniform Resource Locators) that can "link" features or observations to resources that are not stored within the Redbex system.


%Text%

Navigation: Application Server > Content > Associated Data > Links >

Links for features

Last edited: 10/5/2017 11:51:28 AM

To read all links for a specific feature the accessing user must have Read (0) permission on that feature.

To modify (create or delete) attachments linked to a specific feature the accessing user must have Modify (1) permission on that feature.


%Text%

Navigation: Application Server > Content > Associated Data > Links >

Links for observations

Last edited: 10/5/2017 11:51:28 AM

To view links for a specific observation the accessing user must have Read observations (3) permission on the feature the observation belongs to.

To modify links for a specific observation the accessing user must have Modify observations (4) permission on the feature the observation


%Text%

Navigation: Application Server > Content > Associated Data >

Associated Features

Last edited: 10/5/2017 11:51:04 AM

With Associated Features are features linked from one specific feature or observation. Feature associations are part of the Associated Data and you can store with any feature and observation and are also one type of feature relation you can create in Redbex.


%Text%_2

Navigation: Application Server > Content > Associated Data > Associated Features >

Links for features

Last edited: 10/5/2017 11:51:04 AM

To list the features associated with one specific feature the accessing user must have Read (0) permission on that feature.

To modify (create or delete) feature associations of specific feature the accessing user must have Modify (1) permission on that feature.


%Text%_2

Navigation: Application Server > Content > Associated Data > Associated Features >

Links for observations

Last edited: 10/5/2017 11:51:04 AM

To view feature associations for a specific observation the accessing user must have Read observations (3) permission on the feature the observation belongs to.

To modify feature associations for a specific observation the accessing user must have Modify observations (4) permission on the feature the observation


Spatial data

Last edited: 10/5/2017 11:51:42 AM

The Application Server allows to store spatial data with features and observations. Spatial data describes the location, shape and orientation (LSO) of features or observations in space.

Spatial data is used by the Application Server for querying, processing and presenting features and observations in various ways. All spatial data stored with the Application Server will usually only approximate the actual shape and position of the real world phenomenon it represents.

The accuracy of spacial data in Redbex is GIS-like and not geodetic, i.e. the accuracy of all spatial calculations is good enough for all general mapping requirements, but will usually not reach mm precision.


Spatial data support

Last edited: 10/5/2017 11:51:42 AM

The feature type defines the spatial data support for features of its type, i.e. if you can store spatial data for this feature or not, and if spatial data is stored once for the feature or (xor) separately for each observation of a feature.

Table 1 summarizes the possible spatial data support types. The spatial data support is part of the feature type definition and can therefore not be changed by the user.

Spatial data support

Notes

No spatial data support

Used for feature types that have no relation to some real world location.

An Example would be a feature type called Monthly income of employee, where the observations would record the monthly income. In this case neither the feature nor its observations would have any relation to a real world location.

Spatial data for feature (SSF)

Storing spatial data for the feature and storing the feature's observations without spatial data is common for most feature types since it represents the typical scenario when observations are collected over time for a non-moving feature.

An example could be a feature type called Surface temperature, where the observations would represent the surface temperature of a a specific location over time. While the feature itself will have a location, this location will not move over time.

Spatial data for observations (SSO)

Storing spatial data with each observation is usually allowed by feature types where the feature may change its location with every observation. An example would be a feature type called bear sightings, where the feature is one specific bear and each observation records a sighting of a specific bear (e.g. in a national park).

If spatial data is stored for observations, the Application Server can derive spatial information for the feature. For that the Application Server uses either the first or the last observation, or an observation that is closest to a specific date&time.

Table 1: Spatial data support for feature types.


Spatial systems

Last edited: 10/5/2017 11:51:42 AM

The location of a feature or observation is always expressed with reference to a specific spatial reference system that is of one of the following spatial system types supported by the Application Server: Geographic System, Projected System or Axis Reference System.

Based on these types you can define you own spatial reference systems.

The feature type defines which spatial systems types can be used to express the LSO of features of that type i.e. not all feature types allow to specify the spatial location of features in all of the types listed above.

The spatial reference system (and therefore implicitly the also the spatial system type) used to express spatial data is defined on creation of a new feature. Changing the spatial reference system for an existing feature is possible after the feature was created although restrictions apply - as described in following chapters.

If the spatial data support (defined by the feature type) is spatial data for observations all observations of that feature will use the same spatial reference system (and therefore of course the same spatial system type).


Transformation of spatial data

Last edited: 10/5/2017 11:51:44 AM

The Application Server allows the transformation of spatial data. I.e. it can perform the calculations to express the location shape and orientation (LSO) of a real world object specified in a specific spatial system and a specific spatial reference system in another spatial system and spatial reference system.

Not all transformations are possible under all conditions, E.g. spatial data expressed in a Projected system can not necessarily be expressed in an Axis Reference system. See table 1 for details about constraints for transformations between different spatial systems.

Note that transformation from one system to another and also transformations between different reference systems (nearly) always introduce a small error resulting from rounding errors. Therefore transforming to another spatial reference system and then transforming back to the original system will not always result in the same spatial data.

From

To

Notes

Geographic

Geographic

Transformation of data expressed in different geographic coordinate systems is always possible.

Geographic

Projected

In most cases the transformation of a geographic coordinate system to a projected coordinate system is possible. However the general restrictions of map projections apply. E.g. North pole cannot be projected to some projected coordinate systems.

Geographic

Axis Reference

Spatial data defined in a Geographic coordinate system can be expressed in an axis reference system if there is an orthogonal projection of the Geographic geometry to the axis.

For this to be true the spatial data in the geographic coordinate system is first transformed to projected coordinate system on which the axis is defined. After that the a transformation from projected to axis is performed (see below).

Projected

Projected

Transformations of data expressed in different projected coordinate systems is possible. However the general restrictions of map projections apply.

Projected

Geographic

Transformations of data expressed in a projected coordinate system to a geographic coordinate system is possible.

The data is first transformed to the horizontal geographic coordinate system on which the projected coordinate system is defined and then transformed to the specified geographic coordinate system.

Projected

Axis Reference

Spatial data in a Projected system can be expressed in an axis system if there is an orthogonal projection of the Projected geometry to the axis.

The data is first transformed to the projected coordinate system on which the axis is defined (see above) and then the orthogonal projection is done.

Axis Reference

Axis Reference

Transformations of data expressed in different axis reference systems on the same axis are always possible.

Transformations between reference systems belonging to different axes are possible if there is a orthogonal projection of the axis interval in the source axis reference system to the destination reference system.

The data in the source reference system is first transformed to the underlying projected coordinate system after that it is transformed to the underlying projected coordinate system of the target axis and then the orthogonal projection is carried out.

Axis Reference

Geographic

Spatial data in an axis system can always be expressed in any Geographic system.

Axis Reference

Projected

Spatial data in an axis system can always be expressed in any Projected system defined upon a Geographic system.

Table 1: Transformations between spatial systems and constraints for these transformations.


Geographic system

Last edited: 10/5/2017 11:51:22 AM

This spatial system is used to specify location, shape and orientation (LSO) of a feature or observation on or near the surface of earth based on a horizontal geographic coordinate system and a vertical coordinate system.

In a geographic system the LSO of a real world object can be approximated by geometries based on points defined by latitude and longitude together with a reference to the used geographic system. Additionally to this geometry an elevation value can be stored. This elevation value is expressed in the vertical coordinate system that is used by this geographic system. Figure 1 shows how latitude an longitude are measured. Note that the position of the prime meridian is defined by the used horizontal geographic coordinate system.

The Application Server provides a predefined and non-modifiable list of supported horizontal geographic coordinate systems that can be used. The user can combine these predefined horizontal geographic coordinate systems with vertical coordinate systems to form a geographic system. See Table 1 for a summary of settings needed to define a geographic system.

Note that regardless of how coordinates of latitude and longitude are presented they are always stored as decimal degrees internally, i.e. even if the client or some presentation chooses to display coordinates of latitude and longitude in degrees, minutes, seconds and fractional seconds, the data on the Application Server will always store only decimal degrees. The necessary conversions might lead to (marginal) rounding errors.

Operations on geometries in a geographic system use angular computation to work out the result. These computations are based on the ellipsoid model of the earth defined by the horizontal geographic coordinate system. Note that - unless stated otherwise - the elevation is not used in operations done on geometries, i.e. all calculations are done as if the elevation was zero.

Additionally to the shape and the elevation value the Application Server allows to specify a height and a depth of a geometry. These values define the height above the given elevation and the depth below the given elevation value and can be used for an approximation of the real world 3D shape. E.g. if the geodetic geometry describes position and shape of a house, the height extent can be used to specify the height of the house the depth value can be used to define the depth of the houses foundations. The Application Server does usually not use this information in any geodetic calculations. Presentations might however use this information in 3D models.

Figure 1: Latitude and longitude (source: Wikipedia)

Geometries used to specify the LSO of an object in a geographic system are restricted to geographies that cover less than one half of the Earth's surface. While this limitation will rarely affect you, it might produce an error when you define polygon geometries the wrong way. In the geographic system the LSO of a object is defined on a geodetic model of the earth, which is a continuous round surface. Unlike the projected system you can continue going in one direction and will get back to the point where you started. As a result a polygon definition in the geographic system must also tell which side of the polygon contains the area included within the polygon. The key rule to remember is that the area left of path that defines the polygon is included in the polygon, the area right to it is excluded. Therefore when defining a polygon in a geographic system be sure to define it counter clockwise.

In Redbex geographic systems are defined globally. Newly installed Application Server Databases include some predefined geographic systems. Some of these predefined systems are protected and cannot be modified or deleted by the user.

Setting | Description
Name | Name of the Geographic system
Description | Description of the geographic system
Horizontal coordinate system | The used horizontal geographic coordinate system. This must be one out of the predefined list of supported horizontal geographic coordinate systems.
Vertical Coordinate system | The used vertical coordinate system. You can use any of your defined vertical coordinate systems.

Table 1: Settings for a geographic system


Horizontal geographic coordinate system

Last edited: 10/5/2017 11:51:32 AM

Every Geographic system has to be based on a horizontal geographic coordinate system. The Application Server supports a predefined list of horizontal geographic coordinate systems. This list cannot be modified.

See Chapter Supported Horizontal geographic coordinate systems for the list of supported systems.


Changing a geographic system

Last edited: 10/5/2017 11:51:42 AM

Changing the definition of a geographic coordinate system can be done but you should be aware of the consequences. When changing a geographic system the meaning of all spatial data stored with a reference to that geographic coordinate system will change. I.e. the spatial information will not be modified and the therefore the real world position of stored spatial data will change.


Units

Last edited: 10/5/2017 11:51:44 AM

Latitude and longitude values used to specify the shape of an object in a horizontal geographic coordinate system are expressed in degrees. Distances and areas calculated from geodetic geometries are expressed in the unit defined by the horizontal geographic coordinate system (which is in most cases meters and square meters).

See Supported horizontal geographic coordinate systems for details.


Projected system

Last edited: 10/5/2017 11:51:42 AM

This spatial system is used to specify location, shape and orientation (LSO) of a feature or observation on or near the surface of earth based on a projected horizontal coordinate system and a vertical coordinate system.

A projected horizontal coordinate system is a planar two dimensional approximation of the earth's surface. Unlike geographic horizontal coordinate systems, a planar coordinate system has constant length, angles, and areas across the two dimensions. I.e. calculations are done by simple geometrical computations.

Redbex allows you to define (almost) any projected coordinate system. The specification includes the definition of the Projection (the mathematical operation to project objects on the Earth's surface to a planar coordinate system), the linear unit for measuring distances and areas and the vertical coordinate system to be used for elevation values. See Table 1 for a summary of settings used to define a projected system.

In a projected system the LSO of a real world object can be approximated by geometries based on coordinates X and Y together with a reference to the used projected system. Additionally to this geometry an elevation value can be stored. This value is expressed in the vertical coordinate system that is used by this projected system.

Operations on geometries stored with a reference to a projected system use simple geometric computation to work out the result. Note that - unless stated otherwise - the elevation is not used in operations done on geodetic geometries, i.e. all calculations are done as if the elevation was zero.

Additionally to the shape and the elevation value the Application Server allows to specify a height and a depth of a geometry. These values define the height above the given elevation value and the depth below the given elevation value and can be used for an approximation of the real world 3D shape. E.g. if the geometry describes position and shape of a house, the height extent can be used to specify the height of the house the depth value can be used to define the depth of the houses foundations. The Application Server does usually not use this information in any geometric calculations. Presentations might however use this information in 3D models.

In Redbex Projected systems are defined globally. Newly installed Application Server Databases include some some predefined projected systems. Some of these predefined systems may be protected and cannot be modified or deleted.

Setting | Description
Name | Mandatory. Name of the projected system
Description | Optional. Description of the projected system
EPSG Code | Optional. If the defined projected system is using a projection that is defined by the EPSG you can enter the EPSG code here.
Vertical Coordinate system | The used vertical coordinate system. You can use any of your defined vertical coordinate systems.
Linear unit | Mandatory. The linear unit used for horizontal measurement in this projected system
Proj4 Definition | Mandatory. The Proj4 definition string that defines the projection. This must be a valid Proj4 definition string.

Table 1: Settings for a projected system


Definition of the projection

Last edited: 10/5/2017 11:51:12 AM

To be able to transform spatial data to or from a projected system the Application Server must know how details about the projection. There are dozens of different projections that can be used and each of these projections can be configured with several parameters.

For transformations Redbex relies on the widely used proj4 projection library. Therefore the projection details that you have to define with a projected system have to be given as a proj4 configuration string. Documentation on these configuration strings can be found in the proj4 documentation. Please visit the proj4 homepage at http://proj.osgeo.org for more details.

There are several online resources that list the proj4 configuration strings for different projected coordinate systems. E.g. http://www.spatialreference.org/.

The projections supported by Redbex are listed in Table1.

Name of projection | Proj4 proj setting name
Albers Equal Area | aea
Azimuthal Equidistant | aeqd
Airy | airy
Aitoff | aitoff
Mod. Stererographics of Alaska | alsk
Apian Globular I | apian
August Epicycloidal | august
Bacon Globular | bacon
Bipolar conic of western hemisphere | bipc
Boggs Eumorphic | boggs
Bonne (Werner lat_1=90) | bonne
Cassini | cass
Central Cylindrical | cc
Equal Area Cylindrical | cea
Chamberlin Trimetric | chamb
Collignon | collg
Craster Parabolic (Putnins P4) | crast
Denoyer Semi-Elliptical | denoy
Eckert I | eck1
Eckert II | eck2
Eckert III | eck3
Eckert IV | eck4
Eckert V | eck5
Eckert VI | eck6
Equidistant Cylindrical (Plate Caree) | eqc
Equidistant Conic | eqdc
Euler | euler
Extended Transverse Mercator | etmerc
Fahey | fahey
Foucaut | fouc
Foucaut Sinusoidal | fouc_s
Gall (Gall Stereographic) | gall
Geostationary Satellite View | geos
Ginsburg VIII (TsNIIGAiK) | gins8
General Sinusoidal Series | gn_sinu
Gnomonic | gnom
Goode Homolosine | goode
Mod. Stererographics of 48 U.S. | gs48
Mod. Stererographics of 50 U.S. | gs50
Hammer & Eckert-Greifendorff | hammer
Hatano Asymmetrical Equal Area | hatano
HEALPix | healpix
rHEALPix | rhealpix
Interrupted Goode Homolosine | igh
International Map of the World Polyconic | imw_p
Icosahedral Snyder Equal Area | isea
Kavraisky V | kav5
Kavraisky VII | kav7
Krovak | krovak
Laborde | labrd
Lambert Azimuthal Equal Area | laea
Lagrange | lagrng
Larrivee | larr
Laskowski | lask
Lambert Conformal Conic | lcc
Lambert Conformal Conic Alternative | lcca
Lambert Equal Area Conic | leac
Lee Oblated Stereographic | lee_os
Loximuthal | loxim
Space oblique for LANDSAT | lsat
McBryde-Thomas Flat-Polar Sine (No. 1) | mbt_s
McBryde-Thomas Flat-Pole Sine (No. 2) | mbt_fps
McBride-Thomas Flat-Polar Parabolic | mbtfpp
McBryde-Thomas Flat-Polar Quartic | mbtfpq
McBryde-Thomas Flat-Polar Sinusoidal | mbtfps
Mercator | merc
Miller Oblated Stereographic | mil_os
Miller Cylindrical | mill
Mollweide | moll
Murdoch I | murd1
Murdoch II | murd2
Murdoch III | murd3
Natural Earth | natearth
Nell | nell
Nell-Hammer | nell_h
Nicolosi Globular | nicol
Near-sided perspective | nsper
New Zealand Map Grid | nzmg
General Oblique Transformation | ob_tran
Oblique Cylindrical Equal Area | ocea
Oblated Equal Area | oea
Oblique Mercator | omerc
Ortelius Oval | ortel
Orthographic | ortho
Perspective Conic | pconic
Polyconic (American) | poly
Putnins P1 | putp1
Putnins P2 | putp2
Putnins P3 | putp3
Putnins P3' | putp3p
Putnins P4' | putp4p
Putnins P5 | putp5
Putnins P5' | putp5p
Putnins P6 | putp6
Putnins P6' | putp6p
Quartic Authalic | qua_aut
Robinson | robin
Roussilhe Stereographic | rouss
Rectangular Polyconic | rpoly
Sinusoidal (Sanson-Flamsteed) | sinu
Swiss. Obl. Mercator | somerc
Stereographic | stere
Oblique Stereographic Alternative | sterea
Gauss-Schreiber Transverse Mercator (aka Gauss-Laborde Reunion) | gstmerc
Transverse Central Cylindrical | tcc
Transverse Cylindrical Equal Area | tcea
Tissot | tissot
Transverse Mercator | tmerc
Two Point Equidistant | tpeqd
Tilted perspective | tpers
Universal Polar Stereographic | ups
Urmaev V | urm5
Urmaev Flat-Polar Sinusoidal | urmfps
Universal Transverse Mercator (UTM) | utm
van der Grinten (I) | vandg
van der Grinten II | vandg2
van der Grinten III | vandg3
van der Grinten IV | vandg4
Vitkovsky I | vitk1
Wagner I (Kavraisky VI) | wag1
Wagner II | wag2
Wagner III | wag3
Wagner IV | wag4
Wagner V | wag5
Wagner VI | wag6
Wagner VII | wag7
Werenskiold I | weren
Winkel I | wink1
Winkel II | wink2
Winkel Tripel | wintri

Table 1: Supported projections


Changing a projected coordinate system

Last edited: 10/5/2017 11:51:42 AM

Changing the definition of a projected coordinate system can be done but you should be aware of the consequences. When changing a projected coordinate system the meaning of all spatial data stored with features (and their observations) that reference that projected coordinate system will change. I.e. the spatial information will not be modified and the therefore the real world position of stored spatial data will change.


Axis reference system

Last edited: 10/5/2017 11:51:42 AM

This spatial system is used to specify location, shape and orientation (LSO) of a feature or observation on or near an axis that is defined based on a projected system. Axis LSO are given with a reference to a axis reference system defined on top of an axis.

The shape of an LSO in an axis reference system is either a point or a section of the axis placed either exactly on the axis or at a defined offset from it. Table 1 summarizes the data an axis LSO consists of. An axis LSO is defined as empty if start offset and end offset or axis reference system are not given.

Datum

Description

Axis reference system

The axis reference system in which the other parameters are expressed.

Start offset

The offset from the reference system origin that specifies the start of the interval expressed by the LSO.

The unit used to express this offset is the unit defined with the axis reference system.

End offset

The offset from the reference system starting point that specifies the end of the interval expressed by the LSO.

The unit used to express this offset is the unit defined with the axis reference system.

Start offset and end offset together define the orientation of the axis LSO if start offset > end offset the orientation is contrary to the orientation of the axis reference system.

For locations with no length the start offset is the same value as the end offset. These locations will always have the same direction as the used axis reference system.

If the Client does provide an LSO with only Offset 1 or only Offset 2 given the Application Server will automatically set the missing value to the given value. I.e.: If Offset 1 is given and Offset 2 is not given Offset 2 is set to the value of Offset 1. If Offset 2 is given and Offset 1 is not given Offset 1 is set to the value of Offset 2.

Local Coordinate System (LCS) Offset

The real world object described by an axis LSO is not necessarily located directly on the axis. The LCS offset describes the offset of the real world object from the axis using the three dimensional local coordinate system with its origin being on the axis at the specified start offset.

The LCS Offset is a 3D Vector (T, L, H) where T is the transversal offset, L the longitudinal offset, and H the height offset.

The default LCS offset is (0,0,0)

Table 1: Data stored with an Axis LSO


Axis

Last edited: 10/5/2017 11:51:04 AM

Basis for an axis reference system is an axis, the geometrical definition of a poly-line in a projected system. An axis can for example represent a road, a railway track, the center line of a tunnel, a pipeline, or any other linear structure.

Axis definitions are stored in the context of a domains; axis definitions are available in the domain they are created in and in any of its subordinate domains.

The geometrical definition of an axis is always based on a projected system. This is the basis for converting spatial data from axis reference systems to other spatial systems and for performing various spatial calculations.

The geometrical definition is an ordered list of 3D points with coordinates X (Easting), Y (Northing) and Z (Elevation) expressed in the underlying projected system. Unlike spatial calculations in projected systems spatial calculations in axis reference systems always respect the elevation i.e. calculation are always done based on the 3D axis.

For real world axes (used for planning of streets, railway lines etc) a series of X,Y and Elevation points is only an approximation; clearly the number of points influences the accuracy of this approximation. The axis approximated by a series of points will (usually) be shorter than the length of the real world axis, however by specifying enough points the error can be kept in a range that is suitable to your needs.

If you are only interested in a part of a real world axis it is not necessary to specify the geometry of the whole real world axis. You can define a (horizontal and sloped) offset for the first point of the axis. However bear in mind that all calculations that need the actual axis geometry can only be performed in the area where the axis geometry is defined.

The surrounding axis points for a given offset are the axis points where the offset of the first point is smaller or equal the given offset and the offset of the second point is greater than the given offset.

The bearing of an axis at a specific offset is the bearing of the axis projected to the X,Y plane in that point. The bearing is defined by the two surrounding axis points.

Bearing is measured clockwise from the direction of the Y axis in the underlying projected coordinate system (North direction) i.e. the bearing is always a value in the interval [0, 360)°. If the axis is parallel to the Z axis of the underlying projected coordinate system at a given axis offset the bearing at that offset is zero i.e. North. The bearing of the last axis point is the same as the bearing of the fore-last axis point.

The direction of an axis at a specific offset is the direction of the axis projected to the X,Y plane in that point. The direction is the direction of the vector defined by the two surrounding axis points. If the two surrounding points are superimposable in X,Y (i.e. describe a strictly vertical part of the axis) the bearing is 0.

Direction is measured counter clockwise from the direction of the X axis (Easting) in the underlying projected coordinate system i.e. the direction is always a value in the interval [0, 2π)rad. If the axis is parallel to the Z axis of the underlying projected coordinate system at a given axis offset the direction at that offset is π/2.

The inclination of an axis at a specific offset is the inclination of the vector formed by the surrounding axis points i.e. the angle of that vector with the horizontal plane. The inclination of the last axis point equals the inclination of the fore-last axis point. The the inclination a value out of the range [-90,90]°.


Axis simplification

Last edited: 10/5/2017 11:51:04 AM

The definition of an axis might consist of thousands of points especially when the axis is derived from some curved and inclined real world axis. In order to reduce the processing time for various calculations the Application Server can internally use a simplified version of the axis.

If simplification is applied and how much the axis is simplified can be defined by the user. Even if simplification is applied the Application Server still stores the original axis (as defined by the user) the simplified version is created only in memory. Therefore changing the simplification parameters after an axis was defined does not need a redefinition of the axis.

The simplification is done by applying the well known Douglas Peucker Algorithm. The purpose of the algorithm is, given a curve composed of line segments, to find a similar curve with fewer points. The algorithm defines 'dissimilar' based on the maximum distance between the original curve and the simplified curve. The simplified curve consists of a subset of the points that defined the original curve.

The starting axis is an ordered set of axis points and the simplification tolerance ε ≥ 0.

The algorithm recursively divides the axis. Initially it is given all the points between the first and last point. It automatically marks the first and last point to be kept. It then finds the point that is furthest from the line segment with the first and last points as end points (this point is obviously furthest on the curve from the approximating line segment between the end points). If the point is closer than ε to the line segment then any points not currently marked to keep can be discarded without the simplified curve being worse than ε.

If the point furthest from the line segment is greater than ε from the approximation then that point must be kept. The algorithm recursively calls itself with the first point and the worst point and then with the worst point and the last point (which includes marking the worst point being marked as kept).

When the recursion is completed a new output axis can be generated consisting of all (and only) those points that have been marked as kept.

The user can set the simplification tolerance for the algorithm for each axis. The tolerance is interpreted as length units in the underlying projected coordinate system. Setting the tolerance to a value < 0 will disable simplification. However even if simplification tolerance is < 0 the Application Server will still remove double points i.e. will take only the first point of a set of consecutive points with same coordinates.

Setting the tolerance level to zero will eliminate axis points that are linearly dependent. Setting the tolerance to a value greater than 0 will eliminate axis points according to the above described algorithm. Setting the tolerance level to a value lower than zero will disable simplification.

For details about the Douglas Peucker algorithm please consult appropriate literature.

Depending on the axis definition and the setting for the simplification tolerance the simplification can speed up calculations based on the axis geometry significantly especially your axis contains a great number of consecutive (nearly) linearly dependent axis points.

Figure 1: Example for simplification of a curve using the Douglas Peucker Algorithm (source: Wikipedia)


Axis points import file format

Last edited: 10/5/2017 11:51:04 AM

Axis points are defined by importing them from a text file. The text files that can be processed by the Application Server must conform to following formatting rules.

The Application Server tries to automatically detect the character encoding used in the passed text file, it does so by inspecting the files byte order marks (BOM). It automatically recognizes UTF-8, little-endian Unicode, and big-endian Unicode text as well as ASCII text.

The data in the file has to be formatted in rows and columns. Each row (except the header row) describes one axis point. The first column is the X-Coordinate the second column is the Y-Coordinate and the third column is the Z-Coordinate of the axis point. Data in further columns will be disregarded.

The lines must contain the axis points in the right sequence i.e. in the sequence as they define the geometry of the axis.

The column delimiter can be the tab (Unicode U+0009) or the semicolon character (Unicode U+003B). Within one file the same delimiter has to be used. The Application Server auto-detects the used delimiter by inspecting the first line.

The first line in the file is considered to be the header line and is not imported. Lines that cannot be parsed by the Application Server are skipped.

The Application Server provides an Action Log with details about the import.

The strings that describe the numeric values for coordinates X, Y, Z in the source file must conform to following format:

[ws][sign][integral-digits,]integral-digits[.[fractional-digits]][ws]

Elements in square brackets are optional. Table 1 describes each element.

Element | Description
ws | A series of white-space characters.
sign | A negative sign (-) or positive sign (+) symbol.
integral-digits | A series of numeric characters ranging from 0 to 9 that specify the integral part of the number. Integral-digits can be absent if there are fractional-digits.
, | A group separator symbol (Comma)
. | A decimal point symbol (Point)
fractional-digits | A series of numeric characters ranging from 0 to 9 that specify the fractional part of the number.

Table 1: Elements in the numeric format.

Figure 1: Example of an tab delimited import file. Orange arrows show non-printable tab characters.

Figure 2: Example of a space delimited import file. Orange points show non-printable space characters.


Axis reference systems

Last edited: 10/5/2017 11:51:04 AM

On one axis you can define any number of axis reference systems, each with its own specific parameters. Axis reference systems are systems for specifying locations on an axis using a specific start point on that axis, a specific measurement method and a specific measurement direction. Axis reference systems also define the cross sections to use at specific intervals when 'thinking' in this reference system.

Figure 1 shows how axis reference systems are defined on an axis. In this example the geometrically defined axis is only a part of the real world axis. Rs1 is a reference system that with inverted direction, Rs2 is in axis direction. The origin offset of the reference systems are always the offsets to the axis origin (no matter where the geometrically defined axis starts).

Figure 1: Axis reference systems defined on an axis.

Datum

Notes

Origin offset

Defines the start point of the axis reference system on the axis. This value is always given as sloped offset from the axis' origin and is expressed in the length unit defined by the projected coordinate system on which the axis definition is based.

The origin offset must be on the geometrically defined part of the axis. I.e. the start offset for a reference system must be greater or equal than the sloped first point offset defined with the axis.

Default is 0.

Inverted direction

If set the reference system is oriented contrary to the the axis direction. I.e. the higher the offset expressed in that reference system is the lower the offset to the axis origin will be.

Default is No.

Use horizontal measurement

If set this reference system express offsets as horizontal offsets. See chapter Horizontal vs. sloped offsets for more details

Default is No

Offset unit conversion factor

The offsets expressed in an axis reference system are of a specific unit.

This factor is the factor to be applied to the offset values expressed in a specific reference system to get the offset in the unit used by the axis on which the reference system is defined.

The unit used by the axis is defined by the projected coordinate system on which the axis is defined.

This factor must not be zero. Default is 1.

Examples:

If you want to express positions in an axis reference system in km but the projected coordinate system of the underlying axis is using meter the factor must be set to 1000.

If you want to express positions in an axis reference system in feet but the projected coordinate system of the underlying axis is using meter the factor must be set to 0.3048

Offset unit abbreviation

Abbreviation for the unit used for offsets expressed in this reference system.

Default is m.

LCS unit conversion factor

The LCS position for spatial data given in this reference system is expressed in a specific unit. This factor is the factor to be applied to convert the LCS offset to the unit used by the axis's underlying projected coordinate system.

This factor must not be zero. Default is 1.

Example: If you want to use feet as unit for measuring offsets in the LCS of an axis reference system but the underlying axis' projected coordinate system is using meters this factor must be set to 0.3048

LCS unit abbreviation

Unit used to express transversal and vertical offset in axis references that refer to this reference system.

Default is m.

Additive constant

Constant that is included in spatial information based on that reference system.

The constant is either given as a horizontal or as as sloped offset (depending on the Use horizontal offset setting). Can be a positive or negative value. The additive unit is the unit of the reference system, i.e. the formula additive constant * Offset unit conversion factor gives the additive constant in meters.

Default is 0

Table 1: Data specifying an axis reference system


Local coordinate system

Last edited: 10/5/2017 11:51:28 AM

The LCS offset that can be specified in an axis LSO is used to describe the offset of a real world object from a position on an axis. This offset is an offset measured in a Local Coordinate System placed at the start offset specified in the LCS. The LCS is a right handed orthogonal three dimensional Cartesian coordinate system.

The orientation of the LCS is depending on the direction of the reference system used by the Axis LSO and on the inclination of the axis at the start offset of the axis LSO.

For reference system offsets that define a point on the axis where the axis is not vertical, the Transversal (T) LSO axis will always be horizontal i.e. parallel to the X, Y plane. For reference system offsets that define a point on the axis where the axis is vertical this approach does not work therefore the orientation of the transversal axis in vertical coordinate systems is defined by the Y - direction of the underlying projected coordinate system. For more details see tables 1 and 2.

Axis | Description
Transversal (T) | The transversal LCS axis is parallel to the X,Y plane of the underlying projected coordinate system. It is orthogonal to the axis direction vector at the start offset of the Axis LSO. Positive values are on the right of the axis when looking in direction of the LSO's reference system.
Longitudinal (L) | The longitudinal LCS axis is oriented as the axis at the start offset of the Axis LSO. Positive values are in direction of the LSO's reference system.
Height (H) | The height LCS axis is orthogonal to the transversal LCS axis and the longitudinal LCS axis. Positive values are oriented "up", according to the right hand rule.

Table 1: Orientation of the LCS for positions on the axis where the axis is not vertical

Axis | Description
Transversal (T) | The transversal LCS axis is parallel to the y axis of the underlying projected coordinate system (usually the North direction). Positive values are from axis to the North direction, negative values to the South direction.
Longitudinal (L) | The longitudinal LCS axis is oriented as the axis at the start offset of the Axis LSO. Positive values are in direction of the LSO's reference system.
Height (H) | The height LCS axis is orthogonal to the Transversal LCS axis and the Longitudinal. Positive values are oriented "up", according to the right hand rule.

Table 2: Orientation of the LCS for positions on the axis where the axis is vertical


Changing an axis reference system

Last edited: 10/5/2017 11:51:08 AM

Changing the definition of an axis reference system can be done but you should be aware of the consequences.

When changing an axis reference system meaning of all spatial data stored with features (and their observations) that reference that axis reference system will change. I.e. the spatial information will not be modified and the therefore the real world position of stored spatial data will change.


Changing an axis reference system association

Last edited: 10/5/2017 11:51:08 AM

Associating a feature with a different axis reference system will change the axis reference system for spatial data stored with the feature or with all of its observations. Note that you can only change to an axis reference system, that is based on the same axis. The change can be done in two different two ways.

Changing without transformation: This will change the axis reference system without transforming the stored spatial data. I.e it will only change the meaning of the stored spatial data but not its values. The real world position of stored spatial data will change.

Change with transformation: This will change the axis reference system and will transform all spatial data to the new axis reference system. I.e. the real world location of the objects described with the spatial data will not change but the spatial data will have different values and is expressed in another axis reference system.

Note that the transformation of spatial data might introduce rounding errors, i.e. changing back to the original axis axis reference system will usually not produce exactly the same spatial information.


Horizontal vs. sloped offsets

Last edited: 10/5/2017 11:51:22 AM

In many applications that use axes offsets for specifying the location of an object the axis offset is given as horizontal offset, i.e. as offset on the projection of an axis to the X,Y plane of the underlying projected coordinate system. An axis reference system as defined by the Application Server supports this kind of horizontal offset measurement with the Use horizontal offset setting.

For axes that do not contain vertical sections, i.e. where no two consecutive axis points have the same X and Y coordinate and different Z coordinates the mapping of a sloped offset to a horizontal offset is a bijective function i.e. the translation from two different sloped offset values will result in two different horizontal offset values and vice versa.

For axes that contain vertical sections the mapping is not bijective and therefore the transformation between horizontal and sloped offset will either be not possible or not meaningful. The Application Server itself will not check for vertical axis sections it is up to the user to understand the implications of axes with vertical sections.


Deleting axes

Last edited: 10/5/2017 11:51:12 AM

An axis can be deleted only if there is no axis reference system of that axis is used in a feature as spatial reference system. If an axis reference system of the axis to be deleted is used as default axis reference system for a domain this default will be set to null.


Deleting axis reference systems

Last edited: 10/5/2017 11:51:12 AM

An axis reference system can only be deleted if it is not used in a feature as spatial reference system. If the axis reference system to be deleted is used as default axis reference system in a domain, this default will be set to null.


Axis calculations

Last edited: 10/5/2017 11:51:06 AM

This chapter provides technical background on the calculations done with axes and axis reference systems. These calculations are used in various situations, especially when transforming data to to other systems. Note that the transformation of an LSO from or to an axis reference system is more than just transformation of the offsets it also includes handling of the LCS offset and direction.


Reference system offset to axis offset

Last edited: 10/5/2017 11:51:34 AM

The position of a point on axis expressed as offset in a reference system can be expressed as an offset from the axis origin by applying following formulas.

Listing 1: Converting an axis reference system offset to an axis offset for axis reference systems with sloped offset measurement

Listing 2: Converting an axis reference system offset to an axis offset for axis reference systems with horizontal offset measurement


Axis offset to reference system offset

Last edited: 10/5/2017 11:51:04 AM

The position of a point on axis expressed as offset from the axis origin can be expressed as offset in an axis reference system by applying following formulas.

Listing 1: Converting an axis offset to an axis reference system offset for axis reference systems with sloped offset measurement

Listing 2: Converting an axis offset to an axis reference system offset for axis reference systems with horizontal offset measurement


Reference system to reference system

Last edited: 10/5/2017 11:51:34 AM

Converting offsets from one reference system to another reference system on the same axis can be done directly if both reference system use horizontal or both reference systems use sloped offset measurements. Listing 1 shows the formula. If the reference systems use different offset measurement modes the offset has to be converted to axis offset first then to axis offset in the other measurement mode and then to the destination axis reference system.

Listing 1: Direct transformation of offsets between two axis reference systems


Cross section assignment

Last edited: 10/5/2017 11:51:12 AM

Axis reference systems can define the cross sections applied to sections in this axis reference system. Each cross section assignment will assign one cross section available in the domain the axis reference system belongs to with a specific offset interval in that axis reference system.

Cross section assignments must be distinct, i.e. the reference system can define a maximum of one cross section assignment for any offset in that axis reference system. However note that two or more axis reference systems can define different cross sections for the same real world axis position.


%Text%

Navigation: Application Server > Content > Spatial data > Axis reference system >

Mapping Templates

Last edited: 11/8/2017 9:31:16 AM

A mapping template is a two dimensional representation of a 3D geometrical object (e.g. a tunnel, rock slope etc.) that is defined to a specific axis reference system. E.g. for an axis reference system representing a section of a tunnel the mapping template can represent the tunnel walls, roof and floor. In Redbex mapping templates are used as basis for sketching geometrical characteristics of features and observations.

A mapping template consists of one or more mapping template faces and zero or more mapping template information layers.

A mapping template face is a logical part of the two dimensional representation e.g. the left wall of a tunnel. Each face in a mapping template is a set of closed polygons that together specify the geometrical boundaries of the face.

A mapping template information layer is a set of geometrical objects that are used only for visualization. These information layers may be used by clients to improve and annotate the mapping template visualization (e.g. text annotations).

Importing mapping template geometries from DXF files

The geometrical aspects of mapping templates are defined by importing a DXF file. This DXF file must conform to some syntactical and semantic rules described in the following. Since Redbex stores the geometries of mapping templates in WKT format some of the geometries found in the DXF (for example arcs) will be approximated during import.

Supported DXF Versions supported

AutoCad2000, AutoCad2004, AutoCad2007, AutoCad2010 and AutoCad2013 DXF database versions, in both text and binary format.

Reference system

The coordinate system used for the DXF File must be the same as that used for the axis underlying the axis reference system for which the mapping template is imported. I.e. the nodes of geometries in the DXF file must have real-world coordinates expressed in the projected coordinate system underlying the axis reference system.

Hidden layers

Hidden layers will not be processed by Redbex during import.

Mapping template faces

In the DXF file mapping template a face is a set of closed LwPolylines or Polyline DXF entities placed on the same DXF layer. A DXF file must contain at least one mapping template face.

Use the following pattern for the name of DXF layers for mapping faces: Face_<FaceName> e.g. Face_Left Wall.

Redbex will automatically identify DXF layers with the prefix Face_ as mapping template faces. All text after Face_ will be used as descriptive text to explain what part of the template the DXF layer contains.

During import Redbex will approximate the closed LwPolylines by first approximating arcs with straight line segments and the by reducing the number of straight line segments for each polygon by applying the Douglas-Peucker algorithm. Polylines will not be approximated but will be imported with straight line segments between the nodes of the the polyline.

All closed LwPolylines or Polylines on these layers must not be self intersecting and must conform to validation rules listed below.

The DXF layer color will be imported as the mapping template face color and will be used in visualizations.

Any other type of DXF entities on a mapping template face layer will not be imported.

Mapping template information layers

In the DXF file a mapping template information layer is sets of DXF entitites placed on the same DXF layer. A DXF file can contain zero or more mapping template information layers.

Use the following pattern for the layer name: Information_<FaceName> e.g. Information_Intersection Building Parts.

Redbex will automatically identify DXF layers with the prefix Information_ as information layers. All text after Information_ will be used as an identifying name for the mapping template information layer.

During the import following DXF entity types will be read from DXF Information layers:

·LwPolyline: Arc segments are approximated with straight line segments. The resulting polygon is simplified using Douglas-Peucker algorithm

·Polyline: Arc segments in polylines will not not approximated but will be imported with straight line segments between the nodes of the the polyline. The resulting polygon is simplified using Douglas-Peucker algorithm

·Line

·Point

·Circle: Circles are approximated by straight line segments, the resulting polygon is simplified by applying the Douglas-Peucker algorithm

·Ellipse: Ellipses are approximated by straight line segments, the resulting polygon is simplified by applying the Douglas-Peucker algorithm

·Arc: Arcs are approximated by straight line segments, the resulting polyline is simplified by applying the Douglas Peucker algorithm.

·Text: Texts is converted to a point with a label

·MText: Texts is converted to a point with a label

The DXF layer color will be imported as the information layer color and will be used in visualizations.

All other types of DXF entitites found in one of these layers will not be imported.

Validation of geometries

Not all supported DXF entities can be automatically converted to valid WKT geometries. During import all entities are checked for validity. If invalid entities are found the import will try to correct them. The result of this correction might however not result in the desired WKT geometry. It is up to the creator of the DXF file to prevent invalid entitties.

The ActionLog of the DXF import will provide more detailed information on invalid geometries.

The following situations will lead to invalid geometries:

·Not valid because point {0} is an isolated point, which is not valid in this type of object.

·Not valid because some pair of polygon edges overlap.

·Not valid because polygon ring {0} intersects itself or some other ring.

·Not valid because some polygon ring intersects itself or some other ring.

·Not valid because curve {0} degenerates to a point.

·Not valid because polygon ring {0} collapses to a line at point {1}.

·Not valid because polygon ring {0} is not closed.

·Not valid because some portion of polygon ring {0} lies in the interior of a polygon.

·Not valid because ring {0} is the first ring in a polygon of which it is not the exterior ring.

·Not valid because ring {0} lies outside the exterior ring {1} of its polygon.

·Not valid because the interior of a polygon with rings {0} and {1} is not connected.

·Not valid because of two overlapping edges in curve {0}.

·Not valid because an edge of curve {0} overlaps an edge of curve {1}.

·Not valid because some polygon has an invalid ring structure.

·Not valid because in curve {0} the edge that starts at point {1} is either a line or a degenerate arc with antipodal endpoints.

·Not valid because in curve {0} the edge that starts at point {1} is either a line or a degenerate arc with antipodal endpoints.

·Not valid, reason unknown.


Vertical coordinate system

Last edited: 10/5/2017 11:51:46 AM

Vertical coordinate systems are used as reference system for elevation data that is used in geographic and projected systems. Note that vertical coordinate systems are not by itself a reference system for any spatial system they are just used by geographic and projected coordinate systems.

The Application Server allows the definition of any number of vertical coordinate systems. Fore convenience some commonly used vertical coordinate systems are already predefined with every installation of the Application Server. Some of these predefined systems may be protected and cannot be modified or deleted by the user.

See table 1 for a summary of settings you can define for a vertical coordinate system.

Setting | Description
Linear unit | Unit for elevation values. E.g. m for meters
Linear unit code | More descriptive 'unit' name e.g. MTL for mean tide level
Linear unit conversion factor | This is the conversion factor to meters. Vertical coordinate system transformations done in Redbex are based on this value.
Conversion constant | This is the additive constant that is used to transform elevation values from this vertical coordinate system to a base vertical coordinate system.

Table 1: Settings for a vertical coordinate system

Transformation of vertical coordinate systems

The Application Server provides only limited support for transformations of spatial data between different vertical coordinate systems, i.e. it will only transform using a constant shift from and optionally a unit conversion.

For transformation of vertical coordinate systems Redbex assumes that the Conversion constant of all vertical coordinate system defined is converting the elevation data to a common basic vertical coordinate system (that common vertical coordinate system can be virtual - i.e. it does not have to be created in Redbex).

Converting a value given in one coordinate system (VCS!)to another vertical coordinate system is done with following formula:

(value * VCS1.LinearUnitConversionFactor + VCS1.ConversionConstant - VCS2.ConversionConstant) / VCS2.LinearUnitConversionFactor

Calculations on distance and area

Calculations done on geographic or projected geometries do not use elevation data (if not stated otherwise). E.g. the distance between two points is calculated as if the two points would be at elevation zero.


Changing a vertical coordinate system

Last edited: 10/5/2017 11:51:12 AM

Changing the definition of a vertical coordinate system can be done but you should be aware of the consequences.

When changing a vertical coordinate system the meaning of all spatial data stored with features (and their observations) that reference a geographic or projected coordinate system which uses the vertical coordinate system will change. I.e. the spatial information will not be modified and the therefore the real world position of stored spatial data will change.


Digital Elevation Models

Last edited: 10/5/2017 11:51:14 AM

A digital elevation model (DEM) is a digital model or 3D representation of a terrain's surface. Redbex supports DEMs with a regular raster for any coordinate system (Projected or geographic) and utilizes those DEMs to calculate the elevation of positions in that coordinate system.


Choosing a DEM

Last edited: 10/5/2017 11:51:12 AM

Multiple DEMs can be defined for a single coordinate system and the geographic area those DEMs cover might overlap.

The Application Serer supports querying the elevation of a specific position in on specific projected or geographic systems only. When querying the elevation of a specific position the Application Server will first check which DEMs of the selected projected or geographic system cover the position. If more than one DEM covers the position the Application Server will sort those DEMs first by the user supplied sequence number (ascending) and then by (descending) by its cell size.

This means that if the user does not sort the DEMs manually by supplying Sequence numbers the Application Server will automatically choose the DEM with the finest grid for calculating the elevation.

When checking the coverage of a specific position the Application Server will only check if that specific position is within the rectangular bounding box of the DEM. It might still be that the DEM internally does not provide elevation data for that specific position. Figure 1 shows an example: the blue areas in the image are areas that are covered by the rectangular bounding box of the DEM but do not provide elevation values.

Figure 1: Visualization of a DEM (not done with Redbex). Blue areas are the areas not covered by the DEM


Importing DEM data

Last edited: 10/5/2017 11:51:44 AM

The Application Server supports importing of DEM data from ESRI ASCII grid files. The location data found in the import files are interpreted in the context of the coordinate system the DEM belongs to.

A DEM might consist of millions of data points and might therefore get huge in terms of the storage space needed. Redbex will internally separate each DEM into tiles to allow for efficient handling of DEM data. We still recommend that you import only that DEM data you really need to minimize the processing time needed.


DEM import format

Last edited: 10/5/2017 11:51:14 AM

Redbex supports importing DEM data from files in ESRI ASCII raster format also known as ARC/INFO ASCII GRID. This file format is widely used in the GIS world as an exchange, or export format, for raster data.

The file defines the geographic space as an array of equally sized square grid points arranged in rows and columns. Each grid point stores a numeric value that represents a geographic attribute (in this case the elevation) for that unit of space.

The file begins with header information that defines the properties of the raster such as the cell size, the number of rows and columns, and the coordinates of the origin of the raster. The header information is followed by cell value information specified in space-delimited row-major order, with each row separated by a carriage return. The values use the point as decimal separator.

Header format

The header of the file contains a list of keyword value pairs separated by carriage return. Keyword and value are separated by one or more space characters. Table one lists the recognized keywords. All other keywords will be ignored. Keywords are case insensitive. The value in the keyword value pair is always a numeric value.

The parameters in the header part of the file must match correctly with the structure of the data values.

Keyword | Description
NCOLS | Number of cell columns Integer greater than 0
NROWS | Number of cell rows Integer greater than 0
XLLCENTER or XLLCORNER | X coordinate of the origin (by center or lower left corner of the cell). Match with Y coordinate type.
YLLCENTER or YLLCORNER | Y coordinate of the origin (by center or lower left corner of the cell). Match with X coordinate type.
CELLSIZE | Cell size. Greater than 0
NODATA_VALUE | The input values to be NoData in the output raster. Optional. Default is -9999

Table 1: Keywords in the header of a ESRI ASCII grid file.

Data format

The data component of the file follows the header information. The first data line is the first line in the file that does not start with an alphabetic character (A-Z).

Cell values are delimited by spaces. No carriage returns are necessary at the end of each row in the raster. The number of columns defined in the header determines when a new row begins.

Row 1 of the data is at the top of the raster, row 2 is just under row 1, and so on.

Following rules apply when parsing numbers:

·The numeric string can have a leading sign, + for positive and - for negative values.

·The numeric string can include a decimal separator, the decimal separator can be point or comma but must be the same throughout the whole file.

·The numeric string can be in exponential notation. The numeric string may contain an exponent that begins with the E or e character and that is followed by an optional positive or negative sign and an integer. In other words, it successfully parses strings in the form nnnExx , nnnE+xx , nnnE-xx

ncols 1683

nrows 1719

xllcorner 660302

yllcorner 6575838

cellsize 2

nodata_value -3.4028230607371e+038

24.9099998474121 25.0900001525879 25.0699996948242 25.0499992370605 25.0300006866455 25.0799999237061 25.1700000762939 25.2399997711182 25.2399997711182 25.3500003814697 25.3500003814697 25.3500003814697 25.4300003051758 25.4899997711182 25.3500003814697 25.3899993896484 25.4300003051758 25.4500007629395 25.4899997711182 25.5200004577637 25.5900001525879 25.5300006866455 25.5499992370605 25.6599998474121 25.7399997711182 25.75 25.8999996185303 25.9699993133545 26.1700000762939 26.4099998474121 26.5799999237061 26.9300003051758 27.3999996185303

Listing 1: Example of an ESRI ASCII grid file (truncated)


Geometries

Geometries are used for specification of location shape and orientation of of a real world object in geographic and projected spatial systems. In Redbex geometries are used to define the LSO of features observations and are also used as property values for properties of type Geometry.

The basic idea behind geometries is that usually it is not enough to represent the spatial information of a real world phenomenon as simple point (in either geodetic or Cartesian coordinates) and therefore mightier data structures are needed to store more spatial information.

Geometries are a very common concept that is also used within nearly all Geographic Information Systems (GIS) available. The implementation of geometries as provided by the Application Server conforms to the Open Geospatial Consortium (OGC) Simple Features For SQL Specification [2]

To be fully specified a geometry must always map to a specific reference system. This combination of geometry and reference system is called a geometric object. Geometric objects are the basis for geometric calculations and spatial query operators like Overlaps, within, Contains, Disjoint etc.

Both the geographic and the projected or Cartesian spatial system types use Geometries, but there are some key differences in how the data is stored and manipulated.

The defining data for Line-String and Polygon types are vertices only. The connecting edge between two vertices in a geometry type is a straight line. However, the connecting edge between two vertices in a geographic system is a short great elliptic arc between the two vertices. A great ellipse is the intersection of the ellipsoid with a plane through its center and a great elliptic arc is an arc segment on the great ellipse.

In a projected system or in a Cartesian system, measurements of distances and areas are given in the same unit of measurement as coordinates. The distance between (2, 2) and (5, 6) is 5 units, regardless of the units used. With geographic spatial data, coordinates are given in degrees of latitude and longitude. However, lengths and areas are measured in the unit defined by the horizontal geographic coordinate system.

In the projected system or the Cartesian system, the ring orientation of a polygon is not an important factor. For example, a polygon described by ((0, 0), (10, 0), (0, 20), (0, 0)) is the same as a polygon described by ((0, 0), (0, 20), (10, 0), (0, 0)). The OGC Simple Features for SQL Specification does not dictate a ring ordering. In an geographic system, a polygon has no meaning, or is ambiguous, without an orientation. For example, does a ring around the equator describe the northern or southern hemisphere? If we use the geography data type to store the spatial instance, we must specify the orientation of the ring and accurately describe the location of the instance. The interior of the polygon in an ellipsoidal system is defined by the left-hand rule.

Different GIS systems support different types of geometries the following chapters describe the geometries supported by the Application Server.

The feature type defines which geometries can be used to describe its location shape and orientation.


Point

Last edited: 10/5/2017 11:51:16 AM

A point is a 0-dimensional object representing a single location. Since it is 0-dimensional a point has no size and of course also no orientation.

For the geodetic spatial data type a point represents a single given as longitud and latitude. The values for longitud and latitude are measured in degrees. Values for longitud always lie in the interval (-180, 180]. Values for latitude always lie in the interval [-90, 90]. Longitude and latitude are stored as decimal degrees (with double precision), therefore if the client chooses to present this i.e. as DGM (Degree Minutes Seconds) rounding errors might occur.


Multi-point

Last edited: 10/5/2017 11:51:28 AM

A multi-point is a collection of one or more points.


Line-string

Last edited: 10/5/2017 11:51:28 AM

A LineString is a one-dimensional object representing a sequence of points and the line segments connecting them. A line-string has a length but no area.

Figure 1 shows examples of line-string geometries, (1) is a simple, non-closed LineString instance, (2) is a non-simple, non-closed LineString instance, (3) is a closed, simple LineString instance, and therefore is a ring (4) is a closed, non-simple LineString instance, and therefore is not a ring.

Figure 1: examples of line-string geometries


Multi-line-string

Last edited: 10/5/2017 11:51:28 AM

A Multi-Line-String is a collection of zero or more geometry or geography LineString instances. Figure 1 shows examples of line-string geometries.

(1) is a simple Multi-Line-String instance whose boundary is the four end points of its two LineString elements. (2) is a simple Multi-Line-String instance because only the end points of the LineString elements intersect. The boundary is the two non-overlapping end points. (3) is a non-simple Multi-Line-String instance because the interior of one of its LineString elements is intersected. The boundary of this Multi-Line-String instance is the four end points.(4) is a non-simple, non-closed Multi-Line-String instance.(5) is a simple, non-closed Multi-Line-String. It is not closed because its Line-Strings elements are not closed. It is simple because none of the interiors of any of the Line-Strings instances intersect.(6) is a simple, closed Multi-Line-String instance. It is closed because all its elements are closed. It is simple because none of its elements intersect at the interiors.

Figure 1: Examples of multi line string geometries


Polygon

Last edited: 10/5/2017 11:51:30 AM

A Polygon is a two-dimensional surface stored as a sequence of points defining an exterior bounding ring and zero or more interior rings. A Polygon instance can be formed from a ring that has at least three distinct points. The exterior and any interior rings of a Polygon define its boundary. The space within the rings defines the interior of the Polygon.

Polygons are two dimensional geometries, they have an associated length and area. The length of a polygon is measured as the sum of the distances between all consecutive points in all exterior and all interior rings (in other words the length of the shoreline). The area is the area contained within the exterior ring excluding the area contained in the interior rings.

Figure 1 shows example polygon geometries (1) is a polygon instance whose boundary is defined by an exterior ring. (2) is a polygon instance whose boundary is defined by an exterior ring and two interior rings. The area inside the interior rings is part of the exterior of the Polygon instance.(3) is a valid Polygon instance because its interior rings intersect at a single tangent point.

Figure 1: Example of polygon geometries

When polygons are used to define the shape of an object in a geographic coordinate system it is not trivial to classify what is the interior an the exterior area.


Multi-Polygon

Last edited: 10/5/2017 11:51:28 AM

A Multi-Polygon instance is a collection of zero or more Polygon instances.

Figure 1: examples of multi polygon string geometries


Well-Known Text (WKT)

Last edited: 10/5/2017 11:51:46 AM

Well-known text (WKT) is a text markup language for representing vector geometry objects, spatial reference systems of spatial objects and transformations between spatial reference systems. In Redbex WKT is used for geometries for spatial data.

While there it the original specification of WKT[1] and various vendor specific specification of the WKT format, the WKT used in Redbex sticks closely to the OpenGIS Coordinate Transformation Service Implementation Specification issued by the Open Geospatial Consortium[2]. However the implemented WKT parser is robust and might tolerate WKT presentations that are not fully conformant with the above mentioned standard.

This chapter gives a brief overview of the WKT format as used in Redbex, for further reading we suggest to get the original specification from www.opengeospatial.org.


General

Last edited: 10/5/2017 11:51:20 AM

A Well-known Text represents a nested list of entities, with exactly one root entity. Each entity has a keyword in upper case followed by the defining, comma-delimited, parameters of the entity in brackets. The parameters can be strings, numbers, enumerations or other entities. While string, number and enumeration parameters are atomic building blocks of a WKT entity parameters will form a nested structure.

The basic syntax of a WKT is shown in listing 1. Square brackets [ ] can be substituted by standard brackets ( ), but either square or standard brackets must be used consistently within one WKT.

<entity> = <entity keyword>[<parameter>,{<parameter>}*]>

<entity keyword> = Upper case alphanumeric string starting with a letter [A-Z]
containing no white space characters

<parameter> = <string>|<number>|<enumeration value>|<entity>

<string> Any text enclosed with ". The enclosed text must not contain a ".

<number> = {+|-}{[0-9]}*{.<[0-9]>{<[0-9]>}*

<enumeration value> = Upper case alphanumeric string starting with a letter [A-Z] containing no white space characters.

Listing 1: Basic syntax of WKT


Geometry definition

Last edited: 10/5/2017 11:51:22 AM

All the geometries supported by the Application server can be expressed using WKT. Figure 1 shows examples for all supported geometry types. For storing spatial data the Application Server supports 2D and 3D geometries, i.e. geometries without or with elevation values. Evaluation values are not used in any calculation. The application server uses a single elevation value for the whole geometry that is specified alongside the geometry. 4D geometries with an m value are not supported.

Empty i.e. undefined geometries can be defined as shown in Listing 2

POINT (50.12345678901234 60.12345678901234)

POINT (50.12345678901234 60.12345678901234 70.12345678901234)

LINESTRING (50 60, 51 61)

LINESTRING (50 60 70, 51 61 71)

POLYGON ((50 60, 51 61, 62 72, 50 60))

POLYGON ((50 60 70, 51 61 71, 62 72 320, 50 60 70))

MULTIPOINT ((50 60), (51 61))

MULTIPOINT ((50 60 70), (51 61 71))

MULTILINESTRING ((50 60, 51 61), (10 20, 11 21, 12 22));

MULTILINESTRING ((50 60 70, 51 61 71), (10 20 30, 11 21 31, 12 22 32));

MULTIPOLYGON (((50 60, 51 61, 62 72, 50 60)), ((10 20, 11 21, 12 22, 13 23, 10 20)))";

MULTIPOLYGON (((50 60 70, 51 61 71, 62 72 320, 50 60 70)), ((10 20 30, 11 21 31, 12 22 32, 13 23 33, 10 20 30)))";

Listing 1: Examples for a WKT representation of geometries

POINT EMPTY

LINESTRING EMPTY

POLYGON EMPTY

MULTIPOINT EMPTY

MULTILINESTRING EMPTY

MULTIPOLYGON EMPTY

Listing 2: Specification of empty geometries


Spatial indexing

Last edited: 2/13/2018 9:03:58 AM

When storing spatial projected or geographic spatial data the Application Server will automatically convert this data to xxx and xxx respectively and will store this converted alongside with the original spatial data. This is done to utilize the power of spatial indexes


Property structures

Last edited: 11/8/2017 9:31:50 AM

Property structures (PS) are templates for data structures that are used to store data for features and sensors that is specific to the feature type or senor type. Table 1 lists the places where property structures are used.

When a PS is used to store data for a specific object, the Application Server creates a property structure instance (PSI) and fills that instance with data.

Property structure usage | Description
Feature types, type specific feature data | Defines the type specific data that can be stored along with each feature of a specific feature type. This property structure is called the Feature PS.
Feature types, Type specific observation data | Defines the type specific data that can be stored along with each observation in a feature of a specific feature type. This property structure is called the Observation PS.
Sensor types, type specific sensor data | Defines the type specific data that can be stored along with each sensor of a specific type. This property structure is called the Sensor PS
Sensor types, extended chronological | Defines the type specific data that can be stored along with each chronological sensor configuration of a sensor of a specific type. This property structure is called the Chronological sensor PS.
Sensor types, extended observation configuration | Defines the type specific data that can be stored along with each observation that uses a sensor of that specific type. This property structure is called the Sensor observation PS.

Table 1: Areas where property structures are used

While there is some data that is common to all features, sensors, observations etc., property structures are used to store the data that is specific to a specific feature type, sensor type etc.

Property structures cannot be defined or changed by the user but are distributed as part of feature types, sensor types etc, however there are numerous possibilities to configure property structures.

For the technically inclined: a property structure is a dynamic data structure used to store data efficiently without changing the underlying database structures. This allows for distribution of new feature types or sensor types without having to update the database or the Application Server.


Building blocks of property structures

Last edited: 10/5/2017 11:51:32 AM

A property is the atomic data element that is used store data of a specific type within a property structure. Each property is of a specific property type which defines what kind of data (numeric, text, Boolean, etc).can be stored with that property. Besides properties a property structure can also contain collections of other property structures. This way property collections can be used to form one to many relationships with a property structure, i..e. if one instance of a property structure shall contain a series of elements with the same characteristics where the number of those elements can vary.

Example: A property structure used to store type specific data for observations that describe the geological situation at a specific location this description may include any number of rock types observed at this location. In one case you might have just one rock type in other cases you may have five or more. To cleanly represent this, collections would be used.

A property structure containing property collections is called a hierarchical property structure, a property structure containing no collections is called a flat property structure. Since the members of a property collections are also property structures property structures can be nested in any depth

A flat property structure has depth 0, a property structure containing collections which contain only properties has depth 1, a property structure with collections that contain other collections has depth 2 and so on. The level of a property within a property is the collection level in which it was defined. Properties defined directly on the property structure and in no collection are on level 0.

Figure 1 shows a flat property structure, Figure 2 shows a hierarchical property structure. In figure 1 the depth of the property structure is zero, and all properties are on level zero, in figure 2 the depth of the property structure is 2 the property Property Aa1 is on level 2.

Figure 1: Example of a flat property structure | Figure 2: Example of a hierarchical property structure


Property types

Last edited: 11/9/2017 8:05:34 AM

This chapter describes the types of properties that can be used in property structures. It also describes the display settings, default values and validation rules that you can configure for each property of a specific type (as part of the property structure configuration)

Properties of some specific types can be defined as calculated properties. These properties will then not be editable by users but their value will be calculated from other properties in the same property structure.

Mandatory settings

Properties of all property types have a mandatory setting that can be configured as part of the property structure configuration.

Common display settings

Properties of all property types have a common set of display settings that can be configured as part of the property structure configuration. Table 1 shows these common display settings. Each property type can define additional display settings. Note that display settings are hints to the clients accessing the Application Server and might not be implemented by all clients. The Redbex Smart Client does implement all display settings described in this chapter.

Display setting | Description
Display name | Can be used to define a alternate name for this property that can be used to display the property by clients
Display description | Can be used to define a description for this property that can be displayed by clients
Sequence number | Can be used to define in which sequence properties will be shown on clients
Display group name | Can be used to define a property as being part of a group of properties (all properties with the same display group name). Clients can use this information to group the properties visually on the user interface

Table 1: Display settings supported by all property types

Visual appearance

Properties of all property types have a common set of visual settings that can be configured as part of the property structure configuration.

Display setting | Description
Color 1 |

Table 1: Visual appearance settings common to all types of properties


Binary

Last edited: 10/5/2017 11:51:32 AM

Binary type is used to store binary data (usually files). This can be an image, an office document, a video or files of any other type. See file storage for more details on how files are stored by the Application Server and which information is extracted from files.

Display settings

No additional display settings

Default value

No default value can be defined for this type.

Validation rules

Validation rules | Description
Minimum size | Minimum size of the file.
Maximum size | Maximum size of the file

Table 1: Supported validation rules


Boolean

Last edited: 10/5/2017 11:51:32 AM

Boolean properties store a logical value which can be one of the following: TRUE, FALSE or UNDEFINED.

Display settings

No additional display settings

Default value

Default value can be TRUE, FALSE or UNDEFINED.

Validation rules

No validation rules are available for this type.


Classification

Last edited: 10/5/2017 11:51:32 AM

A property of this property type stores a link to one specific element of a classification as property value.

Display settings

Display setting

Description

Display and order type

Defines how elements of the classification shall be displayed, and therefore also defines the ordering of elements if the user did not provide a custom order. Following options are available

·Code, Name: Display the code of the classification element first and then the name. Elements are sorted by code and then name if no custom order is available

·Name, Code: Display the name of the classification element first and then the code. Elements are sorted by name and then code if no custom order is available

Table 1: Additionally supported display settings for this property type

Default value

No default value can be defined for this type.

Validation rules

No validation rules are available for this type, the system always validates that the selected classification element is part of the used classification, see classifications for more details.


Feature link

Last edited: 10/5/2017 11:51:32 AM

The feature link property type allows to link to features from within property structures. A feature link creates a directed relation between two features.

Display settings

No additional display settings

Default value

No default value can be defined for this type.

Validation rules

Validation rules | Description
Only in same domain | If this rule is set to TRUE, only feature that belongs to the same domain can be used.
Only same type | If this rule is set to TRUE, only feature of the same feature type can be used.
Allowed feature types | If set this rule defines that only features of specific types can be linked.

Table 1: Supported validation rules


Geometry

Last edited: 10/5/2017 11:51:22 AM

The geometry property type is used to store a geometry i.e. the location shape and orientation of an object in a Cartesian coordinate system

This property type supports geometries of type point, multi-point, line-string, multi-line-string, polygon, and multi-polygon, however the property structure in which a property of this type is used might limit the supported geometries.

Display settings

No additional display settings

Default value

No default value can be defined for this type.

Validation rules

No validation rules are available for this type.


Multi-select classification

Last edited: 10/5/2017 11:51:32 AM

A property of this property type can store links to multiple elements of a classification.

Display settings

Display setting

Description

Display and order type

Defines how elements of the classification shall be displayed, and therefore also defines the ordering of elements if the user did not provide a custom order. Following options are available

·Code, Name: Display the code of the classification element first and then the name. Elements are sorted by code and then name if no custom order is available

·Name, Code: Display the name of the classification element first and then the code. Elements are sorted by name and then code if no custom order is available

Table 1: Additionally supported display settings for this property type

Default value

No default value can be defined for this type.

Validation rules

Validation rules | Description
Minimum number of selected elements | Minimum number of classification elements that have to be linked
Maximum number of selected elements | Minimum number of classification elements that can be linked

Table 2: Supported validation rules


Numeric

Last edited: 10/5/2017 11:51:32 AM

The numeric property type stores simple numerical values. The value is a double precision value in the range of -1.79E+308 to -2.23E-308, 0 and 2.23E-308 to 1.79E+308, and is internally stored as floating point representation (base=2, precision=53).

Numeric properties can be calculated properties.

Display settings

Display setting | Description
Unit | The unit that is associated with the value of the numeric property. Contrary to the quantity property type this unit is only descriptive. The system cannot convert between different units of numeric properties.
Precision | Number of digits after the comma that are actually displayed to user. E.g. actual precision can be 5 digits after comma, but in a certain context it may be reduced to 3.
No grouping | If set numbers will be displayed without a grouping character, if not set the grouping character as defined in the culture used by the client will be used.
Hide training zeros | If set numbers will not show trailing zeros, if not set numbers will always be shown with the number of digits set with the Precision setting
Validation correction rule | Defines a rule that can be used by clients to detect valid values and automatically correct invalid values to the nearest valid value. See below for a detailed description of validation correction.

Table 1: Additionally supported display settings for this property type

Default value

Default value can be any number in the range of - 1.79E+308 to -2.23E-308, 0 and 2.23E-308 to 1.79E+308.

Validation rules

Validation rules | Description
Minimum value | Minimum value that can be stored with this property
Maximum value | Maximum value that can be stored with this property

Table 2: Supported validation rules

Validation correction

Validation correction is a possibility the Client can implement to assist the user when keying in data manually. The validation correction rule that is part of the display settings of a numeric property defines what values are considered as valid values for this property. Values that are not considered will be automatically corrected to the nearest valid value.

Note that as all other display settings the validation correction rule is stored with the property structure configuration but it is enforced by the client. I.e. validation correction is not performed when importing data.

A validation correction rule defines which values or which ranges of values are permitted. In its simplest form a validation correction rule is simply a semicolon separated list of valid values. You may use both point and comma as decimal separator. Do not use grouping characters. Examples:

1;2;3.5;4;9;7

1,3;2.5;5;9;

Instead of specifying discrete values you can also define ranges.

1:4 would allow all floating point numbers ≥1 and ≤ 4

Ranges can be accompanied by a step width. For ranges with a step width the lower and the upper boundary are always valid values, additionally all values between the lower and the upper boundary where (value - lower boundary) % step width = 0 are also valid values.

1:4|1 would allow values 1, 2, 3, 4

1:5|3 would allow values 1, 4, 5

1:2|0.1 would allow values 1, 1.1, 1.2, ... 2

Finally discrete values, ranges and ranges with step width can be comdined:

1;2.2;10:20|2;22:23;


Quantity

Last edited: 10/5/2017 11:51:32 AM

Properties of type quantity are used to store a numerical values together with the scientific unit of measure. The value of a quantity is its magnitude expressed as the product of a number and a unit, and the number multiplying the unit is the numerical value of the quantity expressed in that unit.

Therefore the value of a quantity type property consists of two parts: the numerical part and the unit part. The quantity property type allows for unambiguous storage exchange and processing of numeric data. Numerical data can be stored in different units of measure and the Application Server provides the possibility to convert between different units of measure. See the chapter Quantities for details on how the Application Server handles quantity values.

The numerical part of the value of a quantity property is a double precision number in the range of -1.79E+308 to -2.23E-308, 0 and 2.23E-308 to 1.79E+308, and is internally stored in binary64 floating point format (see IEEE 754). While floating point representation will be sufficient for nearly every numerical value generated by an observation you should still be aware of the fundamental limits of floating point representations.

Each property of type quantity is of a predefined physical quantity (e.g. length, electric current, force, ...) and for each physical quantity the Application Server supports different units of measures. The unit part of the value of a quantity property is therefore one of the units supported for the physical quantity of for the property.

Internally the Application Server always stores the property value as given by the user, i.e. the Application Server does not convert values internally, unit conversion (if needed) is only done when processing or presenting data. Note that whenever unit conversion takes place there is a chance of rounding errors.

Display settings

Display setting | Description
Precision | Number of digit after comma that are actually displayed to the user. E.g. actual precision can be 5 digits after comma, but in a certain context it may be reduced to 3.
Scientific format | Defines if the value is displayed in scientific notation.

Table 1: Additionally supported display settings for this property type

Default value

Default value can be any numeric value in the range of of - 1.79E+308 to -2.23E-308, 0 and 2.23E-308 to 1.79E+308 and any valid unit for the quantity type of the property.

Validation rules

Validation rules | Description
Minimum value | Minimum value in the given unit that can be stored with this property.
Maximum value | Maximum value in the given unit that can be stored with this property

Table 2: Supported validation rules


Referenced image

Last edited: 10/5/2017 11:51:34 AM

The referenced image property type is used to store digital raster images together with information that defines the size and position of that image in a Cartesian coordinate system.

This property type supports images of type PNG and JPG. See file storage for more details on how files are stored by the Application Server and which information is extracted from files.

The referencing information stored with the image consist of the 'real world' coordinates of the left lower and right upper edge of the image.

Display settings

No additional display settings

Default value

No default value can be defined for this type.

Validation rules

Validation rules | Description
Minimum size | Minimum size of the file.
Maximum size | Maximum size of the file
Valid referenced image | A referenced image is considered valid if all of the following rules are fullfilled. ·Image is given ·Image size is > 5 x 5 pixel ·Coordinates for left lower and right upper edge are given ·Right upper X > Left lower X ·Left upper Y > Left lower Y

Table 1: Supported validation rules


Text

Last edited: 10/5/2017 11:51:32 AM

The text property types stores Unicode text with a maximum length of 4000 characters.

Display settings

Display setting | Description
Text format | Defines how the text stored for this property is formatted. Possible options are plain text or HTML-formatted text.
Multi-line text | Defines if the text stored for this property can span over multiple lines

Table 1: Additionally supported display settings for this property type

Default value

The default value can be any Unicode text with a maximum length of 4000 characters.

Validation rules

Validation rules | Description
Minimum length | Defines the minimum length (in characters) of the data stored for this property. Can be left empty when no minimum length is needed
Maximum length | Defines the maximum length (in characters) of the data stored for this property. Can be left empty when no maximum length is needed. Note that the overall maximum length of 4000 characters for text properties cannot be exceeded
Regular expression | If not empty the data stored for this property must match this regular expression

Table 2: Supported validation rules


Quantities

Last edited: 11/8/2017 9:32:08 AM

In many cases the data of features, sensors and observations we are interested in is data of physical quantities. Therefore property structures can contain properties of type Quantity that allow for unambiguous storage exchange and processing of numeric data that represents physical quantities.

This chapter gives a general overview on physical quantities, unit systems and units and shows how physical quantities are handled by Redbex. It also lists the quantities, units and unit systems that are actually supported by the Application Server i.e. that can be used by properties in property structures. Note that new quantities, unit systems and units may become available with the Online Data Update.

The implementation of Quantities in Redbex is designed upon the International System of Units (SI) but also provides support for units originating form other unit systems. Refer to [4] for more details on the SI system.


Quantities and units

Last edited: 10/5/2017 11:51:32 AM

[3] defines a quantity as: property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference. Hence the value of a physical quantity is expressed as the product of a numerical value and a unit of measurement. A physical quantity is a quantity that can be used in the mathematical equations of science and technology.

Examples of physical quantities are length, mass, and velocity. The value of a quantity is its magnitude expressed as the product of a number and a scientific unit of measure, and the number multiplying the unit is the numerical value of the quantity expressed in that unit of measure.

A unit is a particular physical quantity, defined and adopted by convention, with which other particular quantities of the same kind are compared to express their value. The value of a physical quantity is the quantitative expression of a particular physical quantity as the product of a number and a unit, the number being its numerical value. Thus, the numerical value of a particular physical quantity depends on the unit in which it is expressed. Units are organized in unit systems like the International System of Units (SI), the Imperial System of Units (ISU) or the united states customary units (US)

In today's world most physical quantities are expressed in units of SI, however there are still areas where other unit systems are used. Table 1 shows the unit systems that are used by the Application Server for units of quantities. Note that not all quantities necessarily support all units of all unit systems.

Unit system | Abbreviation | Description
International System of Units | SI | Système international d’unités. Widely used coherent, metric unit system.
Imperial System of Units | Imp | based on the international yard and pound agreement of 1959
US Survey | USS | Only used for units of length quantity. Based on the definition of the foot in the Mendenhall Order of 1893.

Table 1: Unit systems used for units of physical quantities in Redbex

Property structures can contain properties of type quantity that are used to store physical quantities, i.e. the numerical value alongside the unit. The Application Server predefines available physical quantities along with the units that are available for storing values of properties of type quantity. New physical quantities, or units may be added when new feature types or sensor types are installed.

For each physical quantity the Application Server defines a base unit in each unit system. All units of a quantity are derived from the base base unit of the same unit system.

The conversion between units of one quantity is done by first converting the quantity to its base unit. If the target units is not in the same unit system the quantity is next converted to the base unit of the target unit system. After that the quantity is converted to the target unit.

Example: If a quantity given as 1mm shall be converted to inches it is first converted to meters the quantity in meters is converted to feet and finally the quantity in feet is converted to inches.

Any unit conversion can introduce a small rounding error.


Base quantities and derived quantitites

Last edited: 10/5/2017 11:51:06 AM

Analogous to the SI the Application Server defines seven base quantities. Table 1 shows these base quantities along with their corresponding SI base units and dimensions.

Other quantities, called derived quantities, are defined based on these seven base quantities via a system of quantity equations. Each derived quantity can be expressed as term consisting of only base quantities as shown in figure 1.

The derived units for derived quantities are obtained from these equations and the base units. Note that the Application Server only supports unit systems that work define the same base units and that define derived units in the same way.

Quantity | Dimension symbol | Quantity symbol | SI Base Unit
 |  |  | Name | Symbol
Length | L | l | meter | m
Mass | M | m | kilogram | kg
Time | T | t | second | s
Electric current | I | I | ampere | A
Thermodynamic temperature | Θ | T | Kelvin | K
Amount of substance | N | n | mole | mol
Luminous intensity | J | Iv | candela | cd

Table 1: The seven base quantities and their corresponding SI base unit names and symbol

Figure 1: The universal term used to derive a quantity from base quantities

For ease of understanding and convenience 22 SI derived quantities and units have been given special names and symbols. Table two lists these 22 derived quantities together with their SI unit name and symbol. The expression to derive those units from other SI units can of course be expanded to use only SI base units.

Derived quantity | SI derived unit
 | Name | Symbol | Expression in terms of SI units
Planar angle | radian | rad |
Solid angle | steradian | sr |
Frequency | herz | Hz |
Force | newton | N |
Pressure, stress | pascal | Pa | N/m2
Energy, work, quantity of heat | joule | J | Nm
Power, radiant flux | watt | W | J/s
Electric charge, quantity of electricity | coulomb | C |
Electric potential difference, electromotive force | volt | V | W/A
Capacitance | farad | F | C/V
Electric resistance | ohm | Ω | V/A
Electric conductance | siemens | S | A/V
Magnetic flux | weber | Wb | Vs
Magnetic flux density | tesla | T | Wb/m2
Inductance | henry | H | Wb/A
Celsius temperature | degree Celsius | °C |
Luminous flux | lumen | lm | cd sr
Illuminance | lux | lx | lm/m2
Activity of a radionuclide | becquerel | Bq |
Absorbed dowse, specific energy, kerma | gray | Gy | J/kg
Dose equicalent | sievert | Sv | J/kg
Catalytic activity | katal | kat |

Table : Derived quantities with special names as defined in SI


SI prefixes

Last edited: 10/5/2017 11:51:40 AM

SI defines 20 prefixes used to form decimal multiples and sub-multiples of SI units. Table 1 shows the prefixed for positive exponents, table 2 the prefixes for negative exponents. These prefixes are used for units supported by the Application Server.

Factor | Name | Symbol
1024 | yotta | Y
1021 | zetta | Z
1018 | exa | E
1015 | peta | P
1012 | tera | T
109 | giga | G
106 | mega | M
103 | kilo | k
102 | hecto | h
101 | deka | da

Table 1: Unit prefixes defined by the SI with positive exponents

Factor | Name | Symbol
10-1 | deci | d
10-2 | centi | c
10-3 | milli | m
10-6 | micro | µ
10-9 | nano | n
10-12 | pico | p
10-15 | femto | f
10-18 | atto | a
10-21 | zepto | z
10-24 | yocto | y

Table 2: Unit prefixes defined by the SI with negative exponents


Base quantities

Last edited: 10/5/2017 11:51:06 AM

Following chapters describe the base quantities (according to SI) that are supported by the Application Server and lists the units for these base quantities supported by the Application Server.

The seven base quantities are assumed to be mutually independent.


Length

Last edited: 10/5/2017 11:51:32 AM

The SI base unit meter is the length of the path traveled by light in vacuum during a time interval of 1/299 792 458 of a second

Characteristic | Description
Dimension symbol (SI) | L
Quantity symbol (SI) | l

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | kilometer | See SI prefixes |  |
SI | hectometer |  |  |
SI | meter | m | * 1 |
SI | decimeter | See SI prefixes |  |
SI | centimeter |  |  |
SI | millimeter |  |  |
SI | micrometer |  |  |
SI | nanometer |  |  |
Imp | mile | m | * 5280 | 1,609.344m
Imp | yard | yd | * 3 | 0.9144m
Imp | foot | ft | * 1 | 0.3048m
Imp | inch | in | * 1/12 | 0.0254m
USS | survey mile | m | * 5280 | 3600/3937 * 1760
USS | survey foot | ft | * 1 | 1200/3937m
USS | survey inch | in | * 1/12 | 1200/47244m

Table 2: Supported units. Basis units for a unit system are printed in boldface.


Mass

Last edited: 10/5/2017 11:51:32 AM

The SI base unit kilogram is the unit of mass; it is equal to the mass of the international prototype of the kilogram. Note that in SI the kilogram is the base unit, not - as one might expect - the gram.

Characteristic | Description
Dimension symbol (SI) | M
Quantity symbol (SI) | m

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | ton | t | * 103 |
SI | kilogram | kg | * 1 |
SI | gram | g | 10-3 |
SI | milligram | See SI prefixes |  |
SI | microgram |  |  |
Imp | pound | lb | * 1 | 0.45359237kg
Imp | ounce | oz. | * 16-1 | 0.028 349 523 125kg

Table 2: Supported units. Basis units for a unit system are printed in boldface.


Time

Last edited: 10/5/2017 11:51:34 AM

The SI base unit second is the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium-133 atom.

Characteristic | Description
Dimension symbol (SI) | T
Quantity symbol (SI) | t

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | day | day | * 3600 * 24 |
SI | hour | h | * 60 * 60 |
SI | minute | min | * 60 |
SI | second | s | * 1 |
SI | millisecond | See SI prefixes |  |
SI | microsecond |  |  |
SI | nanosecond |  |  |

Table 2: Supported units. Basis units for a unit system are printed in boldface.


Electric current

Last edited: 10/5/2017 11:51:32 AM

The SI base unit ampere is that constant current which, if maintained in two straight parallel conductors of infinite length, of negligible circular cross section, and placed 1 meter apart in vacuum, would produce between these conductors a force equal to 2 × 10−7 newton per meter of length.

Characteristic | Description
Dimension symbol (SI) | I
Quantity symbol (SI) | I

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | gigaampere | See SI prefixes |  |
SI | megaampere |  |  |
SI | kiloampere |  |  |
SI | Ampere | A | * 1 |
SI | milliampere | See SI prefixes |  |
SI | microampere |  |  |

Table 2: Supported units. Basis units for a unit system are printed in boldface.


Thermodynamic temperature

Last edited: 10/5/2017 11:51:34 AM

The SI base unit kelvin, unit of thermodynamic temperature, is the fraction 1/273.16 of the thermodynamic temperature of the triple point of water

The implementation of the thermodynamic temperature quantity in the Application Server differs from the specification in SI. In SI Celsius temperature is defined as derived unit (derived from the thermodynamic temperature), In Redbex Celsius temperature is just another unit of the thermodynamic temperature quantity.

Characteristic | Description
Dimension symbol (SI) | T
Quantity symbol (SI) | Θ

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Kelvin | K | * 1 |
SI | Celsius temperature | °C | + 273.15 |
Imp | Rankine | °R | * 5/9 | * 5/9
Imp | Fahrenheit | °F | + 459,67 | (TF + 459,67) · 5 ⁄ 9

Table 2: Supported units. Basis units for a unit system are printed in boldface.


Amount of substance

Last edited: 10/5/2017 11:51:32 AM

The SI base unit mole is the amount of substance of a system which contains as many elementary entities as there are atoms in 0.012 kilogram of carbon 12. When the mole is used, the elementary entities must be specified and may be atoms, molecules, ions, electrons, other particles, or specified groups of such particles

Characteristic | Description
Dimension symbol (SI) | N
Quantity symbol (SI) | n

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Mol | mol |  |

Table 2: Supported units. Basis units for a unit system are printed in boldface.


Luminous intensity

Last edited: 10/5/2017 11:51:32 AM

The SI base unit candela is the luminous intensity, in a given direction, of a source that emits monochromatic radiation of frequency 540 × 1012 hertz and that has a radiant intensity in that direction of (1/683) watt per steradian.

Characteristic | Description
Dimension symbol (SI) | J
Quantity symbol (SI) | IV

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Candela | cd |  |

Table 2: Supported units. Basis units for a unit system are printed in boldface.


Derived quantitites

Last edited: 10/5/2017 11:51:14 AM

Following chapters describe quantities derived from the SI base quantities that are supported by the Application Server and lists the units for these derived quantities supported by the Application Server.

Derived units are expressed algebraically in terms of base units or other derived units. The symbols for derived units are obtained by means of the mathematical operations of multiplication and division. For example, the derived unit for the derived quantity molar mass (mass divided by amount of substance) is the kilogram per mole, symbol kg/mol.


Acceleration

Last edited: 10/5/2017 11:51:32 AM

Acceleration is the rate at which the velocity of a body changes with time.

Characteristic | Description
Dimension (SI) | L * T-2
Common symbol(s) | a

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | m/s2 | m/s2 | 1 |
Imp | ft/s2 | ft/s2 | 1 |

Table 2: Supported units.


Area

Last edited: 10/5/2017 11:51:32 AM

Area is a quantity that expresses the extent of a two-dimensional surface or shape, or planar lamina, in the plane. Area can be understood as the amount of material with a given thickness that would be necessary to fashion a model of the shape, or the amount of paint necessary to cover the surface with a single coat.

Characteristic | Description
Dimension (SI) | L * L
Common symbol(s) | A

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | square kilometer | km2 | * 103*2 |
SI | hectare(1) | ha | * 102*2 |
SI | square meter | m2 | * 1 |
SI | square centimeter | cm2 | * 10-2*2 |
SI | square millimeter | mm2 | * 10-3*2 |
Imp | square mile | sq mi | * 52802 | (1.609.344)2m2
Imp | square yard | yd2 | * 9 | (0.9144)2m2
Imp | square foot | ft2 | * 1 | (0.3048)2m2
Imp | square inch | in2 | * 1/122 | (0.0254)2m2
USS | square survey mile | m2 | * 5280 | (50500 * 1200/3937)2m2
USS | square survey foot | ft2 | * 1 | (1200/3937)2m2
USS | square survey inch | in2 | * 1/122 | (1200/47244)2m2

Table 2: Supported units. Basis units for a unit system are printed in boldface.

Ad 1) The hectare is one of the non-SI units accepted for use with the SI units.


Electric potential difference

Last edited: 10/5/2017 11:51:32 AM

Electrical potential difference, (also known as Voltage or an electric tension) is the electric potential difference between two points, or the difference in electric potential energy of a unit test charge transported between two points.

Characteristic | Description
Dimension (SI) | L2 · M · S-3
Common symbol(s) | V , ∆V , E

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Kilovolt | See SI prefixes |  |
SI | Volt | V | * 1 |
SI | Millivolt | See SI prefixes |  |

Table 2: Supported units. Base units for a unit system are printed in boldface.


Electric resistance

Last edited: 10/5/2017 11:51:32 AM

The electrical resistance of an electrical conductor is the opposition to the passage of an electric current through that conductor; the inverse quantity is electrical conductance, the ease at which an electric current passes.

Characteristic | Description
Dimension (SI) | M * L2 * I-2 *T-3
Common symbol(s) | R, Z, X

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Megaohm | See SI prefixes |  |
SI | Kiloohm |  |  |
SI | Ohm | Ω | * 1 | V/A
SI | Milliohm | See SI prefixes |  |

Table 2: Supported units Basis units for a unit system are printed in boldface.


Electrical conductivity

Last edited: 10/5/2017 11:51:32 AM

Electrical conductivity or specific conductance is the reciprocal of electrical resistivity, and measures a material's ability to conduct an electric current. It is commonly represented by the Greek letter σ (sigma), but κ (kappa) (especially in electrical engineering) or γ (gamma) are also occasionally used. Its SI unit is siemens per metre (S⋅m−1) and CGSE unit is reciprocal second (s−1).

Characteristic | Description
Dimension (SI) | M-1·L-3·T3·I2
Common symbol(s) | σ

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | µS/m | µS/m | * 10-6 |
SI | mS/m | mS/m | * 10-3 |
SI | S/cm | S/cm | * 102 |
SI | S/m | S/m | * 1 |
SI | S m/mm2 | Sm/mm2 | * 106 |

Table 2: Supported units


Electrical resistivity

Last edited: 10/5/2017 11:51:32 AM

Electrical resistivity (also known as resistivity, specific electrical resistance, or volume resistivity) quantifies how strongly a given material opposes the flow of electric current. Resistivity is commonly represented by the Greek letter ρ (rho). The SI unit of electrical resistivity is the ohm metre (Ω m).

Characteristic | Description
Dimension (SI) | L-3·M-1·T3·I2
Common symbol(s) | Ρ

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Ω mm2/m | Ω mm2/m | * 10-6 |
SI | Ω m | Ω m | * 1 |

Table 2: Supported units. Basis units for a unit system are printed in boldface.


Energy, work, quantity of heat

Last edited: 10/5/2017 11:51:32 AM

Energy is an indirectly observed quantity which comes in many forms, such as kinetic energy, potential energy, radiant energy, and many others

Characteristic | Description
Dimension (SI) | L2 · M · T-2
Common symbol(s) | W

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Megajoule | See SI prefixes |  |
SI | Kilojoule |  |  |
SI | Joule | J | * 1 | N·m
SI | Millijoule | See SI prefixes |  |

Table 2: Supported units Basis units for a unit system are printed in boldface.


Force

Last edited: 10/5/2017 11:51:32 AM

A force is any influence that causes an object to undergo a certain change, either concerning its movement, direction, or geometrical construction.

Characteristic | Description
Dimension (SI) | L * M * T-2
Common symbol(s) | F

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Giganewton | See SI prefixes |  |
SI | Meganewton |  |  |
SI | Kilonewton |  |  |
SI | Newton | N | * 1 |
SI | Millinewton | See SI prefixes |  |

Table 2: Supported units Basis units for a unit system are printed in boldface.


Frequency

Last edited: 10/5/2017 11:51:32 AM

Frequency is the number of occurrences of a repeating event per unit time.

Characteristic | Description
Dimension (SI) | T-1
Common symbol(s) | f, v

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Gigahertz | See SI prefixes |  |
SI | Megahertz |  |  |
SI | Kilohertz |  |  |
SI | Hertz | Hz | * 1 |
SI | Rotations per minute(1) | RPM | * 60 |

Table 2: Supported units Basis units for a unit system are printed in boldface.

The frequency quantity is defined as the number of cycles per second of a periodic phenomenon.

Ad (1): Rotational frequency (e.g. of a machine) is usually not expressed in Hertz but in rotations per minute (RPM). RPM is not a SI unit but is used widely and therefore supported by the Application Server.


Illuminance

Last edited: 10/5/2017 11:51:32 AM

Illuminance is the total luminous flux incident on a surface, per unit area.

Characteristic | Description
Dimension (SI) | L2·L-4·J
Common symbol(s) | Ev

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Lux | lx | 1 | lm/m2

Table 2: Supported units Basis units for a unit system are printed in boldface.


Luminous flux

Last edited: 10/5/2017 11:51:32 AM

luminous flux or luminous power is the measure of the perceived power of light

Characteristic | Description
Dimension (SI) | L2·L-2·J
Common symbol(s) | Φv

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Lumen | lm | 1 | cd·sr (c)

Table 2: Supported units Basis units for a unit system are printed in boldface.


Mass concentration

Last edited: 10/5/2017 11:51:32 AM

The mass concentration is defined as the mass of a constituent divided by the volume of the mixture.

Characteristic | Description
Dimension (SI) | M * L-3
Common symbol(s) |

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | mg / l | mg / l | * 10-3 |
SI | g / l | g / l | * 1 |
SI | kg / m3 | kg / m3 | * 1 |

Table 2: Supported units Basis units for a unit system are printed in boldface.


Plane angle

Last edited: 10/5/2017 11:51:32 AM

Characteristic | Description
Dimension (SI) | L * L-1
Common symbol(s) |

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Radian | rad |  |
SI | Degree(1) | ° | * 180/π |

Table 2: Supported units Basis units for a unit system are printed in boldface.

SI classifies The plane angle as supplementary unit. Considering that plane angle is generally expressed as the ratio between two lengths, SI specifies the quantity plane angle as dimensionless derived quantities. Therefore, the supplementary units radian is to be regarded as dimensionless derived units which may be used or omitted in the expressions for derived units.

Ad (1): A degree (in full, a degree of arc, arc degree, or arcdegree), usually denoted by ° (the degree symbol), is a measurement of plane angle, representing 1⁄360 of a full rotation; one degree is equivalent to π/180 radians. It is not an SI unit, as the SI unit for angles is radian, but it is an accepted unit.


Power, radiant flux

Last edited: 10/5/2017 11:51:32 AM

Power is the rate at which energy is transferred, used, or transformed.

Characteristic | Description
Dimension (SI) | m2 · kg · s-3
Common symbol(s) | P

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Gigawatt | See SI prefixes |  |
SI | Megawatt |  |  |
SI | Kilowatt |  |  |
SI | Watt | W | * 1 | J/s
SI | Milliwatt | See SI prefixes |  |

Table 2: Supported units Basis units for a unit system are printed in boldface.


Pressure, Stress

Last edited: 10/5/2017 11:51:32 AM

Pressure is the ratio of force to the area over which that force is distributed.

Characteristic | Description
Dimension (SI) | L-1 * M * T-2
Common symbol(s) | P

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | Megapascal | See SI prefixes |  |
SI | Hectopascal |  |  |
SI | Kilopascal |  |  |
SI | Pascal | pa | * 1 |
SI | Millipascal | See SI prefixes |  |

Table 2: Supported units Basis units for a unit system are printed in boldface.

Pressure (the symbol: p) is the ratio of force to the area over which that force is distributed.


Specific volume

Last edited: 10/5/2017 11:51:34 AM

In thermodynamics, the specific volume of a substance is the ratio of the substance's volume to its mass.

Characteristic | Description
Dimension (SI) | L3 · M-1
Common symbol(s) | v

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | meter cubed per kilogram | m3/kg | 1 |
Imp | foot per second squared | ft3/poind | 1 |

Table 2: Supported units Basis units for a unit system are printed in boldface.


Speed, velocity

Last edited: 10/5/2017 11:51:34 AM

Velocity is the rate of change of the position of an object, equivalent to a specification of its speed and direction of motion.

Characteristic | Description
Dimension (SI) | L * T-1
Common symbol(s) | v

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | kilometers per hour | km/h | * 3.6-1 |
SI | meter per second | m/s | * 1 |
SI | mm per second | mm/s | * 10-3 |
Imp | mm per hour | mm/h | * 10-3 * 3600-1 |
Imp | foot per second | ft/s | 1 |
Imp | mile per hour | mi/s | * 5280 * 3600-1 |

Table 2: Supported units Basis units for a unit system are printed in boldface.


Volume

Last edited: 10/5/2017 11:51:34 AM

Volume is the quantity of three-dimensional space enclosed by some closed boundary, for example, the space that a substance (solid, liquid, gas, or plasma) or shape occupies or contains.

Characteristic | Description
Dimension (SI) | L * L * L
Common symbol(s) | V

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | cubic meter | m3 |  |
SI | liter | l | * 10*-3 |
SI | milliliter | ml | * 10-6 |
Imp | cubic foot | ft3 | 1 |
Imp | cubic inch | in3 | 1/123 |

Table 2: Supported units Basis units for a unit system are printed in boldface.


Volumetric flow rate

Last edited: 10/5/2017 11:51:34 AM

In physics and engineering, in particular fluid dynamics and hydrometry, the volumetric flow rate, (also known as volume flow rate, rate of fluid flow or volume velocity) is the volume of fluid which passes through a given surface per unit time.

Characteristic | Description
Dimension (SI) | L3 * T-1
Common symbol(s) | Q

Table 1: Quantity brief

Unit system | Unit name | Symbol | Conversion to base unit | Relation to SI units
SI | ml / s | ml / s | * 10-6 |
SI | l / h | ml / s | * 10-3 * 3600-1 |
SI | l / s | ml / s | * 10-3 |
SI | m3 / s | m3 / s | * 1 |

Table 2: Supported units Basis units for a unit system are printed in boldface.


Property structure configuration

Last edited: 11/8/2017 9:31:52 AM

Property structures are deployed by Pöyry Infra GmbH and cannot be modified by the user. However the user can configure properties and property collections within property structures to fit his requirements.

Configurations of property structures are feature configurations and are therefore always created in a specific context. One property structure can have many property structure configurations, but only one configuration in each context.

Which PSCs actually apply for a property structure instance depends on the context in which the instance is used.

E.g. if a property structure configuration for a feature type is defined in the context of a specific domain it will only apply to features in that domain.

Table 2 lists the configuration options available for properties within a property structure, Table 3 lists the configuration options for property collections within a property structure.

Configuration option | Description
Default value | Defines the default value for a property. This value is automatically used as property value whenever a new property structure is created.
Validation rule | Defines validation rules for property values. The available rules depend on the property type.
Display settings | Defines how the property data is (or should be) displayed by clients. The available settings depend on the property type. Note that the client must support display settings for this to be effective.
Visual appearance | Defines how values of this property are displayed in data presentations.
Mandatory setting | Defines if this property is a mandatory property, i.e. if the property structure is only valid if the value of this property is not null.

Table 2: Configuration options for properties within a property structure

Configuration option | Description
Validation rule | Minimum and maximum count.

Table 3: Configuration options for property collections within a property structure


Configuration context

Last edited: 11/9/2017 8:05:12 AM

Each property structure configuration is defined for a feature context, i.e. is applicable only in a specific environment. The context defines under which circumstances the configuration is applicable. This allows you to define different property configurations for the same property structure.

While for a given property structure you can only define one property structure configuration for a specific context, there might be more than one property structure applicable to a specific property structure instance due to inheritance.

E.g. if you define a property structure configuration for the type specific feature data of a specific feature type in a domain, a feature in a sub-domain will inherit that configuration even though a separate property structure configuration might have been defined for the sub- domain.

Table 1 shows the contexts that are used for different property structures

Configurations for | Definition context
type specific feature data, type specific observation data | Feature context
Sensor type specific data, chronological sensor configuration type specific data, sensor observation data | Sensor context

Table 1: Contexts that are used to define the applicability of property structure configurations

When the system searches for property structure configurations for a property structure instance that is used in a specific context it will search for all property structure configurations that are defined in exactly that context or in a context that is superior. For a specific property or collection within the property structure instance the actually used configuration is determined either by unifying all configurations for that property structure or by taking the first matching configuration. Table 2 shows the determination strategy for different setting types.

Setting type | Determination strategy
Validation rules | Unify, All validation rules are verified
Display settings | First match
Alarm conditions | Unify
Default values | First match
Mandatory setting | First match

Table 2: Determination strategies for different setting types


Display settings

Last edited: 11/9/2017 8:05:18 AM

All property types have configuration options that define how the property and its value is displayed (in user interfaces, reports etc.). Besides user defined display configuration the property structure might define default display settings. The effective display settings used are determined by a first match approach.

Note: Display settings are defined for a property but need to be implemented by the client that displays data.


Default values

Last edited: 11/9/2017 8:05:26 AM

For properties of most property types you can define default values. Whenever a new instance of a property structure is instantiated the properties that have default values defined in the current property setting context are set to that value. Additionally the user can reset a properties value to it's default value. Besides the user defined default values the property structure itself might define system default value that is not modifiable by the user. If a user defined default value and a system value are given the user defined default value overrides the system default value. When a property default value is defined it is not checked against the validation rules of the property.

The effective default value used is determined by a first match approach.

Note: the default value is copied to the property data and not linked, therefore if you change the default value later on it will not change any property values.


Mandatory setting

Last edited: 11/9/2017 8:05:34 AM

Mandatory settings define if a specific properties value must be given before it is stored. The mandatory setting can be defined for each property in a property setting context

For some properties system predefined value for mandatory may be available. This value is not modifiable by the user. If system setting is TRUE, property is mandatory, disregarding any user settings. If system setting is FALSE, user setting in current context is used.


Validation rules

Last edited: 11/9/2017 8:05:48 AM

Validation rules can be used to validate data for properties before they are stored. There may be predefined system validation rules and user defined validation rules for each property.

All validation rules for the property that are defined (both system and context specific) are checked when value is modified. If one of the validation rules fail the property value does not validate.

Note: Validation rules are checked only when data is stored. Changing existing validation rules or creating new validation rules does not re-check already stored data. Therefore you might have data in your system that is not valid according to the current validation rules.

Validation rules are mainly intended to help the user when data is entered manually, usually data is imported from other systems (via files or online connection) validation rules do not make sense since you usually want the original data in your system. Additionally, checking validation rules takes time to process - so when huge amounts of data are stored it is wise not to have validation rules in the property setting context of the feature that stores this data.

All validation rules for feature data or observation data can be enabled or disabled together for a feature.


Property collections settings

Last edited: 11/9/2017 8:06:04 AM

The system allows to limit the number of elements within property collections by defining validation rules for the minimum and maximum allowed elements in the collection. Note that as all other validation rules they do not prevent you from storing invalid data, but can be evaluated to detect invalid data.


Permissions for context settings

Last edited: 11/9/2017 8:06:28 AM

To modify settings that are applicable in a specific context the user has to have the appropriate permissions for that context. Table 1 lists the permissions needed for each feature context. Settings can be read by all users that have the appropriate permission in the given context

Context | Permissions needed
Feature | To define settings in the context of a specific feature the user must have the Modify (1) feature permission on that feature.
Domain + feature type + feature subtype | The user must have the domain permission Modify feature settings (15) on the selected domain the permissionModify feature settings (4) on the feature type.
Domain + feature type | The user must have the domain permission Modify feature settings (15) on the selected domain and the permissionModify feature settings (4) on the feature type.

Table 1: Permissions needed to create and modify feature settings with a specific feature setting context

To modify settings that are applicable in a specific sensor context the user has to have the appropriate permissions for that sensor context. Table 1 lists the permissions needed for each sensor context. Settings can be read by all users that have the appropriate permission in the given context

Context | Permissions needed
Sensor | To define settings in the context of a specific sensor the user must have the Modify sensor permission on that feature.
Domain + sensor type | The user must have the domain permission Modify feature settings on the selected domain for the selected feature type

Table 1: Permissions needed to create and modify feature settings with a specific feature setting context


Validation of property structures

Last edited: 11/8/2017 9:31:52 AM

The Application Server can validate property structure instances using user defined validation rules that are defined as part of property structure configurations.

Validation of property structures initiated directly by user request or alternatively initiated by a stored job definition.

Validation of property structures is performed as job. Validation can therefore only be successful if the user requesting the validation has the Create and modify job system permission.

Validation of property structures is always performed in the context of the user requesting the validation. This has following implications

·Only property structures for which the accessing user has read permission can be validated

·Validation results will only be visible for the initiating user


Validation run

Last edited: 10/5/2017 11:51:44 AM

When validation for property structures is requested (either directly by a user or through a validation job) a new validation run is created on the Application Server. With the validation request comes the definition of the validation subjects. The subject of a validation run can be a list of validation objects of the same type. Table 1 shows the available validation objects.

Note that for a successful validation of the validation subject the user requesting the validation must have the appropriate permissions to read data of that object.

After creation of a validation run that run is immediately put on the job queue and will start as soon as the job engine gets it from the job queue. The results of the validation run are stored as a validation result structure.

A validation run always has a defined status. Table 2 lists the status a validation run can be in.

Validation object type | What is validated
Feature | type specific feature data
Feature including observations | type specific feature data and type specific observation data of all observations of the feature
Feature including observations and sensor configurations | type specific feature data and type specific observation data of all observations of the feature and sensor configuration data of all observations.
Observation | Type specific observation data
Sensor | Type specific sensor data
Sensor including chronological sensor configuration | Type specific sensor data and type specific data of all chronological sensor configurations of the sensor
Chronological sensor configuration | Type specific data of all classification elements of a classification
Classification | Type specific data of all classification elements
Classification element | Type specific data of the classification element

Table 1: Validation object types

Status | Description
Waiting for execution | The validation run was not yet started
In progress | The validation run is currently being processed by the Application Server
Finished without violations | The validation run is finished. All validation subjects conform to the validation rules.
Finished with violations | The validation is finished at least one property in a property structure of at least one validation subject violated the validation rules.
Job could not be started | The validation job could not be started due to missing Create and modify job system permission.

Table 2: Validation run status


Validation result

Last edited: 10/5/2017 11:51:44 AM

The result of a validation run is a hierarchically structured list that holds validation results for each validation subject. The validation result includes information on violation or non violation of the validation rules that apply to the validation subjects.

Each node in the validation result has a success status. Table 1 lists the used success status.

The validation result represents the conformance of the data stored with property structure instances with the validation rules that apply to the property structure instances, at that point in time when the validation was run. I.e. the validation is outdated as soon as someone changes data in the validated property structures.

Success status | Description
Unknown | The success status of this node is not known. The reason can be that the validation is not yet finished.
Passed | No violations of the validation rules detected.
Failed | Violations of the validation rules were found
No permission | The use who initiated the validation run does not have the permission to read the data of the validation subject.
Subject not found | The subject to be violated was not found. This can happen if the subject was deleted.

Table 1: Success status for a validation subject


Classifications

Last edited: 12/15/2017 9:13:00 AM

A classification is a set of elements that is used to describe some characteristic. E.g. the classification {Granite, Latite, Tachylyte} could be used to describe the rock found at a specific location.

In Redbex classifications are used in property structures as values for properties of type classification or multi-select classification. Classification and multi-select classifications in property structures are important to standardize stored data and therefore also to provide a high quality of data.

Compared to simple textual information the usage of classifications - either in classification or multi-select classification property types - has the advantage that they standardize the vocabulary used to describe a specific characteristic.

From the example above we already see that a single classification that describes a single characteristic might not be enough. In different locations you will have different geological situation and therefore a different set of rock types. For ensuring a high quality of your data you therefore need different classifications to describe rock in different locations, i.e. the same characteristic is described with different classifications in different locations.

Redbex therefore pre-defines only the available classification types (i.e. the characteristic that shall be described). For each classification type the user can define any number of classifications including any number of classification elements. The classification type is therefore the container that can hold different classifications used to describe the same characteristic.

Classifications are bound to domains and only available within that domain and its sub-domains.

Example: Redbex defines a classification type named Rock that is used in more than one feature type to describe the geological situation at a specific location. Which types of rocks are used to describe the geological situation is usually defined by some national or international standard or perhaps also by a company standard or project standard. Therefore you can create any number of classifications for this classification type. In our example you would perhaps create one classification that consists of elements according to a German standard and another one according to an ISO-standard.


Classification type

Last edited: 12/4/2017 6:15:40 AM

Each classification implements a specific classification type. The classification type defines what characteristic classifications of that type describe. Classification types are deployed by Pöyry Infra GmbH with modular updates. The user cannot create, modify or delete classification types.

When a property structure is deployed along with feature types or sensor types and the property structure contains a property of type classification or multi-select classification the classification type of that property is already set to one specific classification type. This assignment cannot be changed by the user. However the user can change the classification used.


Classification

Last edited: 10/5/2017 11:51:10 AM

For each classification type the user can create any number of classifications. A classification is a container that holds classification elements. Each classification is created in a domain and available in that domain as well as in all subordinate domains.

Each classification has a name and a description that can be set by the user. The name is mandatory.

A user can modify a classification and the elements of a classification if he has Modify Classifications (13) permission on the domain the classification belongs to and if he has Modify classifications (2) on at least one feature types that uses this classification type for one of its properties.


Classification element

Last edited: 12/4/2017 6:21:48 AM

Classification elements are the contents of a classification they form the vocabulary of the classification i.e. they are the actual values that can be selected when entering data for properties of type classification or multi-select classification.

For each classification element the system stores a code, a name, a description and a sequence number. The name is mandatory and must be unique within the classification. The code can be empty but if given must also be unique within the classification. The description can be used to further describe the classification element. The sequence number can be used to force a specific ordering of the classification elements.

The user can define the visual appearance for each classification element. When values of classification properties are visualized the visualization (e.g. map, chart etc) can choose to use these visual appearance settings.

Using property structure configuration users can define the preferred ordering of classification elements For each property of type classification or multi-select classification the user can set the preferred ordering of elements to Sequence + Name + Code or, Sequence + Code + Name.


Defining the used classification

Last edited: 12/4/2017 7:36:08 AM

The classifications available in a specific domain for a specific classification type are all classifications that are defined in this domain or in any of it's parent domains (downward propagation in domain tree). To be able to enter data in property structures using that specific classification type, one of these available classifications must be set as the used classification. To set the used classification on a domain the user must have the Feature type permission Modify classifications (2) and the domain permission Modify Classifications (13) on the domain where the used classification shall be set.

Note: For each classification type you can only define one used classification in a domain.

When creating a new classification for a classification type that does not have a classification yet in the domain in which the new classification shall be created, the new classification will be automatically set as used classification.

Example: If in the domain structure pictured in Figure 1 the Root domain defines Classification A and Classification B and the Domain 1 defines a Classification C then the available classifications in Domain 1 would be A, B and C. Now in Domain 1.1. the user can choose to use A as classification and in Domain 1.2. he can use to choose C.

Figure 1: Example domain structure

As a rule of thumb you will create standard classifications in a high level domain, and less widely used classifications in lower level domains.


Creating all missing classifications

Last edited: 12/1/2017 3:03:16 PM

When installing Redbex there will be no classifications for any of the classification types. Also if new classification types are introduced (via modular updates) the system will not create any classifications for these new types.

To speed up the process of creating classifications the Application Server provides the possibility to create classifications within a domain for all classifications that do not have a classification yet. Following conditions are checked for each classification type in the domain on which this functionality was called:

1.If the classification type is not used i.e there is no feature type or sensor type installed that uses this classification, no classifications will be created.

2.If the classification type has no available classifications in the domain:

·If the executing user has the appropriate permissions a new classification will be created for this classification type in the selected domain. The classification will be named like the classification type with the post-fix (Default) (localized to the language of the executing user)

·The newly created classification will be set as the used classification for the selected domain.

2.If the classification type already has exactly one available classification

·If the executing user has the appropriate permissions the one available classification is not set as the used classification it will be set as used classification.

3.If the classification type has more than one available classification

·Nothing will be changed.

The Application Server writes an action log that includes details about the checks performed and changes applied.


Transferring classification elements

Last edited: 12/1/2017 3:59:46 PM

The Application Server supports transferring (exporting and importing) classification elements. This is useful when working with multiple installations of Redbex (e.g. when using a test and a production environment).

The transfer will always work within the context of a domain and a set of classification types and will transfer elements for the used classifications of each of these classification type in this domain only. The set of classification types can either be all classification types in the system or all classification types used by a specific feature type.

Only elements of classifications where the user has read permission on the domain the classification belongs to will be exported. When importing only those classification elements will be imported that belong to classification types that can be edited by the executing user.

The transfer does not handle classifications themselves but only the classification elements within the used classifications, i.e. the export file does not have any information about the classification but is basically a list of classification elements that have a tag that identifies to which classification type they belong. This way the classification element transfer is independent of the specific structure of the domain tree and the names of classifications.

Export steps

For each classification type:

1.Get used classification of classification type in the context domain

2.Get elements of the used classification and write them in the export file

Import steps

For each classification type:

1.Get used classification of classification type in the context domain

2.Get all elements in the export file for the classification type

3.Write those elements to the used classification

The result of an export will be provided as output file. The Application Server writes an action log that includes details about the export and import process.


Deleting features and observations

Last edited: 11/8/2017 9:27:32 AM

For deleting features and observations Redbex uses a two step approach. When the user deletes a feature or an observation that feature or observation is first just marked as being deleted and will removed from the database by a purging procedure that runs in the background afterward.

I.e. the feature or observation will be immediately marked as being deleted but will be purged from the Redbex Application Server database at some later (non deterministic) point in time.

This two step approach is implemented for optimizing the system performance especially when deleting big amounts of features or observations.

Data affected when deleting a feature

When a feature is deleted (and eventually) purged following data is irreversibly deleted

·The feature itself (including base data, type specific data, spatial data etc.)

·If the feature is linked by another feature or observation through a property of type feature link, the value of the property will be deleted.

·If the feature is a platform feature all the features belonging to that platform will be released (not be linked to the platform any more)

·If the feature is a group feature all the group members will be released (not member of that group any more)

·If the feature is used in calculated feature algorithm it will be removed (possibly breaking the algorithm)

·If the feature instantiated other features, those instantiated features will be released, i.e. it is not traceable any more where the instantiated feature came from.

·If the feature is member of a platform, group or network or platform it will of course also be removed from that.

·Alias names in alias schemes for this feature

·Any associated data of the feature

·Any property structure configuration of that feature

·Any privileges where the feature is privilege object

·Any approval workflows assigned to the feature will be deleted

·Observations of the feature - see below for more details

Data affected when deleting an observation

When an observation is deleted (and eventually purged) following data is irreversibly deleted

·The observation itself (including base data, type specific data, spatial data etc.)

·Any assigned Approval workflows

·All observation alarms

·Any associated data of the observation


Details on the purging process

Last edited: 10/5/2017 11:51:32 AM

Purging of features and observations that have been marked as deleted runs as a background tasks on the Redbex Application Server. Whenever a feature or observation is deleted the task of purging that feature or observation (i.e. deleting data from the Redbex Application Server Database) is put onto a purge-queue.

A purging background process will monitor the purge-queue and will actually delete the features or observations on that queue one by one. If big amounts of features and observations are marked as deleted in a short period of time the purge-queue will grow since the process of purging might take longer than the marking features or observations as deleted. I.e. the time it takes for a feature or observation to be actually removed from the Redbex Application Server Database varies according to the size of the purge-queue the overall system load etc.

The Application Server also implements a prioritization on the purge queue i.e. it is not guaranteed that the first deleted feature or observation is also the first to be purged.

The purging process runs as a single thread i.e. purging of elements on the queue is done sequentially.

When the Application Server starts up it will check for all features and observations marked as deleted and will initially fill the purge queue. Therefore after an ungraceful shutdown of the Application Server content purging will resume immediately when starting the Application Server again.

Monitoring the purging process

The process handling the purge-queue and actually deleting data from the Redbex Application Server Database updates the performance counters Content purging queue size and Content purging average time.


Data import

Last edited: 11/8/2017 9:02:02 AM

I many cases the data for features and observations that you want to keep in Redbex is available digitally as files, in databases or in other data sources. The data import allows you to connect to these data sources and import data for features and / or observations to Redbex.

When importing data Redbex must of course know how to read data in the data source and how to interpret the data in that data source. Redbex therefore provides a set of import types that can handle different types of data sources and different types data formats.

Any import is performed in two main steps. In Step 1 the import process connects to the specified data sources and transforms the data using the logic of the import type to an intermediate data format. In step 2 the import process takes data from that intermediate format and persists it to the Redbex Application Server database.

Figure 1: Main steps of the import process


Import definition

Last edited: 12/13/2017 7:03:46 AM

To import data you first have to create an import definition. The import definition advices the Application Server where it can find the data to be imported and how this data shall be processed during import.

Import definitions can be created on-the-fly or can be persisted as import templates for repeated execution.

Import templates are import definitions that are persisted on the Application Server in the context of a domain. You will typically create import templates when you intend to repeatedly execute that import definition with different or changed data sources.

Import templates can either be private or public. Private import templates are visible only for the user who created them. Public import templates are visible to all users who have domain permission Read (0) on the domain the import template is associated with. To create modify or delete public import definitions users must have the Manage import definitions (20) permission.

Setting | Description
Settings for stored import definitions (only used when persisting the import definition as stored import definition)
Name | Name of the import definition. This can be empty for on-the-fly imports.
Grouping path | The path that can be used by clients to display stored import definitions in a tree-like structure.
Description | Description of the import definition.
Private | If set the stored import definition will be private to the user who created it.
Origin domain | The domain that the stored import definition is associated with. Note that an import definition might be associated with one domain, but might still import data for another domain.

Table 1: Settings for import templates

An import definition will always import data into one specific domain. I.e. if the import creates new features those features will always belong to the same domain, if the import searches for existing features to update it will only search in that domain (see Feature matching for more details).

An import definition consists of:

·Specification of import type

·Name and description of the import definition (only for stored import definitions)

·Specification of import sources (e.g. files, databases)

·Specification of common settings (settings available for all imports disregarding the import type, General import settings for more details)

·Specification of import settings specific to the chosen import type

·Specification of the import sources from which data is imported


General import settings

Last edited: 1/17/2018 9:26:50 AM

General import settings are available for every import type.

Setting name

Description

Target domain

This is a mandatory setting.

Each import session created from an import definition must target a specific domain. This domain will be used for following:

·Resolve feature that are already in Redbex

·Find alias schemes

·Domain for newly created features

Create new features

If set, the import session will create new features (and if present their observations) found in the import data sources. If not set new features (and again their observations) will not be created.

The import type decides what is a new feature by trying to match features found in the sources against features already existing in Redbex. The logic for this matching is different for each feature type.

Update existing observations

If set, data of already existing observations (observations with the same sampling time as an observation in the import source) stamp will be overwritten with the data from the import source. Note: Updating observations results in a deletion of existing observations and creation of new observations.

Update existing features

If set, data for already existing features (features in Redbex that could be mapped to the features found in the import source with the logic of the import type) will be updated with the data from the import source

Import session name

The identifying name that will be used for all import sessions that are created from this import definition. This setting is optional but is useful when tracking import logs etc.

If no import session name is defined the Application Server will choose a default name.

Import session description

Description that will be added to all import sessions that are created from this import definition. This setting is optional but is useful when tracking import logs etc.

Table 1: Settings in the General group

Time conversion

Settings in this group are used to define how the Application Server shall handle Date-Time values read from the source(s) when converting them to Date-Time-Offset.

Setting name

Description

Conversion type

Defines which conversion type shall be used when converting Date-Time values. Two options are available:

·Time zone: With Time Zone conversion Date-Time values are interpreted using the Time Zone defined in the Time Zone setting.

·Fixed offset: With Fixed offset conversion Date-Time values are interpreted using a fixed offset. I.e. all Date-Time values in the source are assumed to have the same offset from UTC.

Time Zone

This setting is only effective if Conversion type (see above) is set to Time Zone.

Defines the time zone used to convert Date-Time values to Date-Time Offset Values.

Default: Application Server's Operating System Time zone.

Fixed offset

This setting is only effective if Conversion type (see above) is set to Fixed Offset.

Defines a time span (in minutes) that is used to convert Date-Time values to Date-Time Offset Values.

Default: Application Server's Operating System Current Time Offset..

Table 2: Settings in the Time conversion group

Group feature memberships

Settings in this group are used to define if features created or modified by the import shall be added as members to the specified group features.

Setting name

Description

Apply to

This setting defines which features that are added or updated by the import will actually become a member of the specified group features.

No feature: Disables adding features to groups

New features: Only features newly created

Existing features: Only modified features (i.e. features where either feature data or observations have been modified) will be added as group members

New and existing features: combination of the above.

Group feature 1

Feature to which all features created and/or modified by the import shall be added as group member.

Group feature 2

Feature to which all features created and/or modified by the import shall be added as group member.

Group feature 3

Feature to which all features created and/or modified by the import shall be added as group member.

Table 3: Settings in the Group feature membership group

Advanced settings

Settings in this group are usually only for advanced users, they allow you to fine tune your import definition.

Setting name | Description
Alias scheme | This is an optional setting. Defines the alias scheme to be used for resolving feature names found in the source files. If no alias scheme is given the Application Server will resolve feature names in the source files with the real feature names stored on the Application Server
Skip errors | If enabled the import will skip errors if possible, if not enabled the import will break if an error is detected, e.g. when reading a malformed source file. Default: False
Break after conversion | If set the import definition will not actually create or modify features or observations but the import will break after the data was read from the import sources. This setting is useful when trying to read data from a new source since it will report all errors during reading from that source and will not create any features or observations. Default: False
Edit mode setting | Can be used to advice the importer to set the editing mode of newly created observations. Default: None

Table 4: Settings in the Advanced settings group


Feature matching

Last edited: 12/13/2017 7:03:10 AM

When importing data Redbex has to match features found in the import sources against features already existing in Redbex, so that the feature data and observation data in the import sources can be imported to the right feature in Redbex and so that the import can determine what data shall be imported to features that are not yet in the Redbex.

The actual logic how features found in the import sources are matched to features already existing in Redbex is defined by the import type. However all import types have the same basic logic:

The import will only search for matches in the set of features that are member of the same data domain as the target data domain set in the import definition (including all sub-domains). Additionally only those feature will match where the feature type is the same as the feature type the import type suggests for the data in the sources.


Adding to group features

Last edited: 12/13/2017 7:44:26 AM

When importing data newly created features or features that are already existing in Redbex but are somehow updated or modified by the import process can be added to specified group features. This is especially useful if you want the imported features to inherit feature directives from the specified group features.

If features are added to group features and to which group features they are added is defined in the general import settings (and therefore this possibility is available for every import type).

If a feature is added to a group feature during the import process this is done before any observations are created or updated by the import process, therefore all feature directives inherited from the specified group features are effective for newly created or updated observations.


Import sessions

Last edited: 12/13/2017 7:03:52 AM

Whenever a import definition is executed an import session is created on the Application Server. Import sessions therefore provide a history of data imports performed from a specific import definition.

Import definitions that have not been persisted as import templates before the definition was executed will record the import session as On-the-fly import session. Imports executed from stored import definitions will record the import session linked to that stored import definition.

Linking of features and observations to import sessions

All features and all observations that are created during an import are linked to that import session. Note: If an observations is updated by an import session the old observation is actually deleted and then a new observation is created. The linking of features and observations to import sessions is used by Redbex

Source files

Import sessions for import types that read data from files can optionally store the original source files. If source files were stored with an import session the user may delete those source files at a later point in time without deleting the import session or deleting the data created or modified by the import session.


%Text%

Navigation: Application Server > Content > Data import > Import sessions >

Deleting import sessions

Last edited: 12/13/2017 7:04:40 AM

Import sessions can be deleted by the user who initiated them. Deleting an import session will not revert the changes the session introduced. The links between the import session and features or observations will be deleted but the features and observations themselves will remain.

Files that were associated with the import session will be deleted along with the import session.


Deleting linked features and observations

Last edited: 3/7/2018 1:42:56 PM

The Application Server provides the possibility to delete features and observations linked to an import session. When deleting the features and observations for an import session following content will be deleted:

·all features created the import session

·all observations created or altered by that import session, even if these observations have been modified after the import. Will also delete any associated data for these observations

For more information on what data is destroyed when deleting a feature or observation please see chapter Deleting features and observations.

Note that the deleting of linked features and observations this is therefore not a full featured undo of an import session and shall therefore be used with caution. Anyhow it can be a useful functionality in cases when you encounter wrongly imported data.

Deleting of linked features and observations will of course respect the current permissions the user has on features and observations, therefore it is be possible that a user cannot delete features and observations created by an import session that this user ran. In that case the Application Server will revert all changes where permissions are granted all other changes will remain untouched.


Import source types

Navigation: Application Server > Content > Data import >

Import sources

Last edited: 12/13/2017 7:04:14 AM

There are different types of sources from which the Application Server can fetch the files to be processed in an import session. Table 1 summarizes these different source type.

Source option | Description
File Sources (source for import is one or more files in a specific format)
File depot | This source type can be used to import from files from a user's file depot. This source type will not be persisted in stored import definitions, but is available for on-the-fly import definitions.
FTP server | This source type is used to import from files located on an FTP server .
Application Server directory | This source type is used to import from located in a directory of the Application Server.
Databases
Database | Generic database source. Can be used only for import types that support reading data from another database.

Table 1: Source types for import files


File Depot

Last edited: 12/13/2017 7:03:42 AM

This source type allows to specify files from the user's file depot as source files for the import. Once the import processed files from the upload vault they are automatically removed from the file depot.

This source specification cannot be used for stored import definitions (the specification will not be persisted). However it is useful in in on-the-fly import definitions.


FTP

Last edited: 12/13/2017 7:04:04 AM

This source type is used to specify files located on an FTP server (and that are therefore accessible through the FTP protocol) as source files for the import.

The connection to the specified FTP Server will be created from the Application Server. Therefore it is necessary that the Global Settings for FTP connections are set correctly.

This source type will process all files on a specified FTP server in a specified directory on that server that match the given file mask. Additionally a date and time can be given to limit the files to files that were update after that given timestamp.

The Application Server supports the option to only import files that were changed after the last execution of the import definition. The option Only files modified after last import is of course only respected for stored import sessions. If set this option will advice the Application Server to import data only from files that were modified after the last successful import session was started.

The Only files modified after last import option uses the last update time stamp provided by the FTP Server to decide if a file shall be imported or not. Only files with a last modification timestamp that is greater than the timestamp when the last successful import session was started will be downloaded and imported. Note that some FTP Servers do not always provide precise values for date & time and do not support date-time-offset values. Therefore it may be that this option behaves not as wanted especially when FTP Server and Application Server are in different time zones.

Table 1 lists the settings that are available for an import source of type FTP.

Setting | Description
Server | The DNS name or IP address of the FTP server
Port | The FTP Server's Port
Passive | Defines if passive FTP mode shall be used when connecting to the FTP server.
Timeout | Timeout in [s] for FTP commands
Username | The username to use for authentication on the FTP server.
Password | The password to use for authentication on the FTP server. The password is stored within the Application Server as symmetrically encrypted string.
Path | Path on the FTP server where the files to be imported are located.
File mask | A regular expression defining which files shall be imported, if empty all files will be processed.
Minimum last update date | The minimum last updated time stamp a file must have to be imported.
Only files modified after last import | Only useful for stored import definitions. If true, only files that were changed after the begin of the last import session will be processed

Table 1: Settings for the FTP source


Application Server directory

Last edited: 12/13/2017 7:04:14 AM

This source type is used to specify files located a directory on the Application Server. This source type may be useful in a single computer installation scenario or when the source files are put on Application Server via FTP Server, shared network storage etc.

This source type will process all files in a specified directory (a directory on the Application Server or a directory that can be accessed from the Application Server) that the given file mask. Additionally a date and time can be given to limit the files to files that were update after that given timestamp.

Table 1 lists the settings available for this source type. Note that the directory specified will be accessed as the Windows User running the Application Server Windows Service. Be sure to set the Windows access rights to the specified directory accordingly.

Setting | Description
Path | Path on the local file system or UNC path to a folder in the local network.
File mask | Regular expression defining which files shall be imported, if empty all files will be imported
Minimum last update date | The minimum last updated time stamp a file must have to be imported. Use this setting to skip old files in a directory.

Table 1: Settings for the Application Server directory source


%Text%

Navigation: Application Server > Content > Data import > Import sources >

Database

Last edited: 12/13/2017 7:04:22 AM

This source type is used to a connection to a database from which the Application Server can directly gather data. This import source in only supported by some specific import type.

This import source stores a connection string to a database.


Import types

Last edited: 2/1/2018 6:22:52 AM

The Application Server provides multiple import types. An import type encapsulates the logic how to read and process a source file of a specific format. Which import types are available for you depends on your license.


3D Movement in Tunnel

Last edited: 12/8/2017 7:43:54 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


%Text%

Navigation: Application Server > Content > Data import > Import types >

Generic (customizable)

Last edited: 12/8/2017 7:47:20 AM

This import format is a generic format that can be used to import features and observations data for any feature type. It can read data from a wide range of tabular-structured data files, by allowing you to define which column in the source file contains what information as well as many other settings. This import type gives you great flexibility to adapt to the structure of a given source file.

The file format expected by generic import type is a text file structured in lines and columns.


Encoding and line breaks

Last edited: 3/9/2018 10:25:16 AM

A line in the source file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

The character encoding of the source files can either be specified in the import settings or can be automatically detected by Redbex.

The character encoding detection built into Redbex is based on a port of the Universal Charset Detector of Mozilla. This charset encoding detection is able to detect the character encodings shown below

Detection of the character encoding is however in many cases non-deterministic, i.e. the character encoding of a file or a series of bytes can only be detected with a certain probability.

·UTF-8

·UTF-16 (BE and LE)

·UTF-32 (BE and LE)

·windows-1252 (mostly equivalent to iso8859-1)

·windows-1251 and ISO-8859-5 (cyrillic)

·windows-1253 and ISO-8859-7 (greek)

·windows-1255 (logical hebrew. Includes ISO-8859-8-I and most of x-mac-hebrew)

·ISO-8859-8 (visual hebrew)

·Big-5

·gb18030 (superset of gb2312)

·HZ-GB-2312

·Shift-JIS

·EUC-KR, EUC-JP, EUC-TW

·ISO-2022-JP, ISO-2022-KR, ISO-2022-CN

·KOI8-R

·x-mac-cyrillic

·IBM855 and IBM866

·X-ISO-10646-UCS-4-3412 and X-ISO-10646-UCS-4-2413 (unusual BOM)

·ASCII


Whitespace and comments

Last edited: 12/8/2017 7:47:14 AM

Leading and trailing white space characters (see table 1) will be automatically trimmed from each line. If the column separator is set to tab (U+0009) tabs will not be trimmed. The first character of a line is defined as the first non-white space character, the last character as the last non-white space character.

Lines where the first characters (after trimming) equals the user-defined Comment Designator (see table 2) are treated as comment lines and will be ignored. If a comment designator is contained in a line, but is not the first character in the line it will be treated as data.

Empty lines (i.e. lines that only contain white space characters) are ignored.

Each non-comment and non-empty line is separated into cells by the user-defined column separator character (see table 2).

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).

Table 1: White space characters that are removed from the beginning or end of a string when a string is trimmed


Feature matching

Last edited: 12/13/2017 7:02:46 AM

For matching features found in the source files the %Text% import type will use following logic:

The import will only search for matches in the set of features that are member of the same data domain as the target data domain set in the import definition (including all sub-domains). Additionally only those feature will match where the feature type is the same as the feature type this import type suggests for the data in the sources (see topic Column mapping).

If a spatial reference system is set in the import configuration (see topic Column mapping) this import type will only match existing features if the spatial reference system of the existing feature is the same as the spatial reference system defined in the import settings.


Configuration

Last edited: 12/8/2017 8:00:30 AM

Setting | Description
General
True value text | If the string in a cell that is treated as Boolean cell equals this text, the value in this cell is treated as Boolean True. All other strings will be treated as false. This comparison is done is case sensitive on the trimmed (see table 1) value of a cell.
Null value | If the string in a cell matches this string the Application Server will treat this cell as Null. This comparison is done is case sensitive.
Column separator | This specifies the character used in the source files to delimit columns. You can choose from a list of predefined characters.
Merge multiple separators | If this flag is not set one column separator character advices the Application Server to skip to the next column. If this flag is set, consecutive column separator characters will be treated as a single separator character.
Number of header lines | This defines the number of lines from in the beginning of the file that are treated as header lines and will therefore not be parsed.
Comment designator | If a line in the source file starts with this text, it is treated as comment line, i.e. it will not be parsed by the import.
Column mapping | This setting allows you to define the column mapping, i.e. the association of columns in the source file with specific properties of the feature or observation to be imported. See Column mapping for more details
Localization Settings that are used to handle localized data.
Date time format | The pattern that is used to parse date time values given as string in the source files. See Date-time formatting for more information on date time patterns. Note that the Culture setting (see below) will also used for the interpretation of the date time pattern defined here.
Culture | The culture used for parsing date time values (see also above), numeric values etc.

Table 1: Import type specific settings


Column mapping

Last edited: 12/8/2017 7:47:14 AM

The flexibility of this import type is mainly founded in the possibility to map columns in the source files to specific properties or other characteristics of the feature or observation to be imported. The column mapping is part of the import type's specific settings. The column mapping consists of some general settings (see table 3) and a series of column associations (table 4).

Setting

Description

Store source files

If enabled the source files that were imported with each import session created from this import definition, will be stored on the Application Server and linked to the import session. This option gives you the possibility to store the original data files along with your import session.

Default: false

Feature type

Defines the feature type of the data to be imported.

Container feature type

This import format supports the creation of container features and the mapping of features to these container features. This setting defines the feature type of container features to be created.

Feature name resolving

With this import type you have different possibilities how the import shall detect the name of the feature for which data is imported.

·Fixed feature: Import data for a fixed (see below) feature.

·Read from file name: Read feature name from (a part of) the file name. You can use a regular expression to filter out the part of the file name that defines the feature name.

·Read from column: Read feature name from a specific column of the source file. If set to this option you will have to define a column mapping for the feature name.

Feature

This setting is only available if the Feature name resolving is set to Fixed feature.

Defines the feature for which data shall be imported.

Container Feature

This setting is only available if the Feature name resolving is set to Fixed feature.

Defines the container feature for which data shall be imported.

Regular expression for feature name

This setting is only available if the Feature name resolving is set to Read from file name.

Here you specify a regular expression that is used to define the part of the file name that specifies the feature name. The actual feature name will be the match for the first sub-expression of that regular repression.

Example:

Original file name: AB_123-4.csv

Regular expression: AB_([0-9]{3}-[0-9])\.csv

Resulting feature name: 123-4

Regular expression for container feature name

This setting is only available if the Feature name resolving is set to Read from file name. See above for a description how to use regular expressions for defining the feature name.

Spatial system of feature

Defines the type of spatial system to use for newly created features.

Spatial System of container feature

Defines the type of spatial system to use for newly created container features.

Axis reference system

Only available if Spatial system of feature is set to Axis reference.

Defines the axis reference that shall be used with newly created features.

Table 1: General settings for the column mapping

Setting

Description

Column index in file

This is the 1-based (meaning first column as index 1) index of the column(s) that is/are mapped to a single property or characteristic of a feature ore observation.

User can define a single column index or a range or collection of column indices that will be read from the source file and written to a property that is mapped. Multiple columns can simply be defined by specifying a comma separated list of column indices, or column ranges.

Examples:

·1-3, 5 will map column 1, 2, 3 and 5

·7-9 or will map column 7, 8, 9

·1, 2, 3, 4, 7-9 will map column 1, 2, 3, 4, 7, 8, 9

Multiple column indices will only be respected if you choose Join Columns with delimiter as pre-processing type (see below). If not only the first index will be mapped.

Pre-processing type.

You can select a pre-processing step that is performed before the source string is treated as value. Following pre-processing types are available:

·None: No pre-processing will be performed

·Join Column with delimiters: Multiple columns in the source file are concatenated using the specified delimiter.

Example:

·Input file has following data:
axis; point_id; datetime; value
*KW23*; *4*; 2015-07-23 09:34; -32,43

·Expected output is
name: *KW23-4*
date: 2015-07-23 09:34
value: -32,43

·Then user can configure the import like so:
Column index: 1,2
Preprocessing type: Join columns with delimiter

Post-processing type

Post processing takes the result of the pre-processing as input and processes the text accordingly. If there is no pre-processing then it simply takes the content of a single column.

Post processing takes place after pre-processing, the output of the post processing is then mapped to the property of the feature.

·None: No post processing is performed.

·Split and take word: Split the value with given split character and take the word at given (1 based) index .
Needs two settings: Split character(the character[s] that will be used to split the text and Word number to take(which word to take after split). Example: if input text is 'KW23-4', user wants to extract the "KW23" and map to a property then the post processing definition should be: Split characters: -, Word number to take: 1.

·Skip from beginning and end: Defines how many characters to be ignored from the beginning and from the end of the input text. This processor has two settings: Characters to skip at the beginning and characters to skip at the end. Example: the post processor gets an text: "abc4957xyz" as input. User wants to extract the numeric part of the text i.e. 4957 and map to a column. The post processing settings will be: Characters to skip at the beginning: 3, Characters to skip at the end: 3. Output is: 4957

Property unit

If a mapping is done for a property of property type quantity. you have to choose the unit of the values in the source file.

All imported values will be interpreted as values in this unit.

Table 2: Settings for each mapped column


Container relations

Last edited: 12/8/2017 8:00:18 AM

This import type also supports container relationships. It is possible to select name of a container feature as one of the columns. In this case all features created during import will be linked to a container feature, whose name is defined in the corresponding row. It is also possible to specify the spatial system typoe and spatial reference system of container features. Non-existent container features will be created.


Generic (simple)

Last edited: 12/8/2017 7:40:20 AM

This import format is a generic format that can be used to import features and observations data for all feature types.

Table 1 shows which data can be imported with this import type. The import type can create features that are not currently present in the domain to which the import is targeted. Existing features will not be changed in any way.

Data

Notes

Feature Name

New features can be created automatically, observations for already existing features will be appended to that feature.

Feature subtype

Newly created features can be imported with the right feature subtype (if provided by the import file)

Subtype for existing features will not be changed.

If the source file contains conflicting subtypes for the same feature (in different lines) the first defined subtype will be used.

Observation base data

Sampling Timestamp

Result timestamp

Erroneous flag

Type specific observation data

All data for properties on level 0 of the property structure the type specific observation data

Table 1: Data that can be imported by the generic text import type

The file format expected by generic import type is a text file structured in lines and columns. The text file can include Unicode characters encoded as UTF-8 (which is backward compatible to ANSI with codepage 65001). The file may use a BOM (Unicode byte order mark) to specify the byte order of the character encoding.

A line in the source file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Leading and trailing white space characters (see table 2) will be automatically trimmed from each line. If the column separator is set to tab (U+0009) tabs will not be trimmed. The first character of a line is defined as the first non-white space character, the last character as the last not white space character.

Lines where the first character is a # (U+0023, UTF-8: 0x23) are treated as comment lines and will be ignored. If the # is contained in a line but not the first character in the line it will be treated as data. Empty lines (after trimming) except the first non-comment line after the first header line are ignored.

Each non-comment and non-empty line is separated into cells by the column separator character. The column delimiter character can be set in the import type's settings. Only one column delimiter character is allowed between two columns, i.e. for n columns you need exactly n-1 column delimiters, and column n is the column after the n-1th column delimiter.

The first two non-comment and non-empty lines are treated as header lines. Header lines contain processing information for the import. The first header line is used to define the contents of a column by specifying a column content identifier in each cell. This column content identifier is used by the Application Server to match the data in that column to some characteristic of the feature or observation. Columns with a column content identifier that is not recognized by the Application Server are ignored. The second header line is used to define the unit for numeric values if these numeric values are matched against a quantity property in the observation's type specific data property structure.

Since the column headers in header line 1 define the contents of each column, the sequence of columns is not important, however all mandatory columns need to be present. The Generic text import type defines some columns that can or must be present in every source file (see table 3). The identifiers of the properties in the type specific data property structure of the observation for the feature type that is imported are used as column content identifiers for additional feature type specific columns. See the documentation of the feature types for more information.

The data in the columns (after the header lines) can be of type numeric (and quantity), text, date & time and boolean. Table 3

Figure 1: Example for an import source file used to import distance observations

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).

Table 2: White space characters

Column header identifier | Mandatory |
FEATURE |  | Name of the feature or Alias name (if an alias scheme is used)
FEATURE_SUBTYPE |  | Name of the feature subtype Default: null
OBSERVATION_SAMPLINGTIMESTAMP |  | Sampling timestamp of the observation. Must be a unique sampling timestamp.
ERRONEOUS |  | Specifies if the observation is erroneous Default: false

Table 3: Common columns for the generic text import format

Setting | Description
String | Any unicode string. The column separator is not allowed within the string.
URI | Any URI. The column separator is not allowed within the string.
Quantity | A numeric value that is read as quantity. The number must not contain grouping characters. The unit is deriver from the second header line.
Numeric | A numeric value that is read as quantity. The number must not contain grouping characters.
Boolean | A three valued Boolean value (true, false, null). The strings yes, true and 1 are interpreted as true (case insensitive), everything else is interpreted as false (except the null value string which is of course interpreted as null)
Date time | A date time offset value that conforms to the date time format string and date time culture given in the general import settings.

Table 4: Supported data types with the generic import type.

Setting | Description
General
Feature type | The feature type for which the data shall be imported
Null value | The string that identifies a null value. If a cell contains a string that equals this null value string the value will be interpreted as null. If left empty empty cells will be interpreted as null. If set to a non-empty value and a cell contains an empty value this will result in an error.
Column separator | The column separator to be used
Store source files | If enabled the source files that were imported with each import session created from this import definition, will be stored on the Application Server and linked to the import session. This option gives you the possibility to store the original data files along with your import session. Default: false
Spatial location
Spatial system | Defines the spatial system to use for features created by the import.
Axis reference system | Defines the axis reference system to be used for newly created features. Only used if Spatial System is set to Axis.
Coordinate system | Defines which coordinate system is used with newly created features. Only used if Spatial System is set to Coordinate system
Date time format | The format used to parse date time offset values. The Date time format is always based on the selected culture (see below). For more details on date time formats see chapter Date & time formatting
Date time culture | The culture used to parse date time offset values. Specifics of each of the selectable cultures can be found in the

Table 5: Settings of the import type generic text


%Text%

Navigation: Application Server > Content > Data import > Import types >

GVR

Last edited: 12/8/2017 7:40:24 AM

GVR is a text based file format for transferring water table data originating from a software product called Autograph. The GVR format has changed over the years and there is no official documentation on the exact syntax of GVR. Therefore it is hardly possible to provide a GVR parser that will support all kinds of GVR files out there; however Redbex is able to parse a wide range of differently formatted GVR files. Below you find a description of the GVR file format as understood by Redbex.

Each GVR files contains data for one Redbex feature. The GVR import therefore will create or update one feature of type Ground water level for each GVR file. Details about what data is parsed and stored during can be found below.

Note: During import some of the values found in the GVR source files have to be translated to Redbex classification elements. It is therefore mandatory for this import that in the domain where the GVR files are imported used classifications are defined for classification types Aquifer type, Drill hole type and Standard comment.

The Import type specific settings are shown in table 1.

Setting

Description

Store source files

If enabled the source files that were imported with each import session created from this import definition, will be stored on the Application Server and linked to the import session. This option gives you the possibility to store the original data files along with your import session.

Default: false

Coordinate system

Mandatory.

GVR files can contain spatial information (Easting, Northing) about the location of the ground water level. For correct interpretation of these values the user must select a coordinate system. The GVR import supports only projected coordinate systems.

All newly created features will be set to this coordinate system.

Value type

Can be either Relative or Absolute. If Relative is chosen Redbex will convert the data in the source files to absolute values using the values of inclination and pipe top edge found in the source file.

Create classification elements

If set the import will try to create missing classification elements in used classifications for classification types Aquifer type, Drill hole type and Standard comment.

Note that the user executing the import has to have the permission to modify classification elements of these classifications for this setting to have effect.

Table 1: Import type specific settings

Physical structure of GVR files

GVR files are text files that can be in different encodings, Redbex supports UTF-8, UTF-16 or UTF-32, ASCII (7 bit), ANSI, for ANSI encoding Redbex will try to guess the code page. The file may use a BOM (Unicode byte order mark) to specify the byte order of the character encoding.

A line in the GVR file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

The file stem (= file name without extension) of a GVR file defines the ID (or name) of the ground water measurement point. The extension of the file is not relevant in Redbex but is usually GVR.

All numeric values in the GVR files use the point as decimal separator.

Logical structure of GVR files

GVR files consist of two parts: The mandatory header and the optional data part.

The first nine lines in the GVR file are interpreted by Redbex as the header lines. Each of these lines consists of one or more cells separated from each other by one or more spaces (SPACE, U+0020, UTF-8: 0x20). The exact meaning of each line and each cell in those lines is shown in Table 1.

All lines following the ninth nine header lines to the first line containing only the * character (ASTERISK, U+002A, UTF-8: 0x2A) are interpreted as comment lines and will not be used by Redbex in any way. The line with the single * character, terminates the header.

Line | Cell | Meaning
1 | 1 | Numerical value. Optional. Default is null. Defines Northing of the ground water measurement point. Northing and Easting and Elevation (see below) are used by Redbex to locate the measurement point. The values of Northing and Easting are interpreted in the Coordinate system the user has chosen in the import format settings.
2 | 1 | Numerical value. Optional. Default is null. Defines Easting of the ground water measurement point.
3 | 1 | Numerical value. Default is null. Terrain elevation at the ground water measurement point.
4 |  | Numerical value. Optional. Together Section and Distance (see below) provide an alternative way of defining the ground water measurement point location. Redbex does not use this information.
5 | 1 | Numerical value. Optional. Distance. Not used by Redbex (see above)
6 | 1 | Alphanumeric value. Mandatory. Type of the drilling (e.g. classified by casing. The type of drilling can be any alphanumeric string (without spaces). In Redbex this string ins translated into a classification element by case insensitive comparison of the string in the GVR file with the code of the classification elements of the used Drilling Type classification.
 | 2 | Alphanumeric value. Mandatory. Defines if the GVR file contains exact points in time or just dates for each reading. A value of -1 or a Ja (case insensitive) indicates that the data part has time values. Any other alphanumeric value indicates that the data part has no time values.
 | 3 | Alphanumeric value. Optional. Not used by Redbex
7 7 | 1 | Numeric value. Mandatory. Elevation of top edge of pipe (= Reference elevation if data is interpreted as depth values). Use -999 if top edge is unknown. Note that in that case depth values cannot be converted to absolute values. Values less than -100 or greater than 10000 are invalid.
 | 2 | Numeric value. Optional (Default value 0). Bearing of the drilling given in compass degrees. If the drilling is not a perpendicular drilling this cell gives the direction of the drilling. For a perpendicular drilling the value of this cell shall be 0. Values < 0 or greater 360 will be normalized to a range in [0, 360]
8 | 1 | Numeric value. Mandatory. Final depth of the drilling expressed as elevation. Use -999 if final depth elevation is unknown Values less than -100 or greater than 10000 are invalid.
 | 2 | Numeric value. Optional. Default is 90 Inclination of the drilling given in degrees. 90 is perpendicular down, -90 is perpendicular up. Values less than -90 or greater than 90 are invalid.
9 | 1 | Numeric value. Mandatory. Default is null Filter length must be greater than 0. Use -999 if filter length is not known or not applicable.
 | 2 | Numeric value. Mandatory. Average value of measurements. Not used by Redbex.
 | 3 | Alphanumeric value. Optional. Default is empty Type of aquifer (classified by its geological characteristics). The type of aquifer can be any alphanumeric string (without spaces). In Redbex this string ins translated into a classification element by case insensitive comparison o f the string in the GVR file with the code of the classification elements of the used Aquifer Type classification.

Table 2: Description of header lines and cells in the GVR file format

All lines after the line with a single * terminating the header are interpreted as data lines. Empty lines are ignored. The first line with a single * after the start of the data part is terminating the data block and the GVR file. Any data after that line is ignored. If no such line is found for the data part Redbex will read all data till the end of the file.

The contents of a data line is again organized in cells. The first 5 cells are mandatory (have to be present in any GVR file) and are separated by one or more spaces. Table 2 describes the meaing of these 5 cells.

Cell No | Description
1 | Numeric value. Mandatory. Year when measurement was taken
2 | Numeric value. Mandatory. Month when measurement was taken
3 | Numeric value. Mandatory. Day when measurement was taken
4 | Numeric value. Mandatory. Measured value. This value is interpreted either as depth or as absolute elevation. Depending on the import format settings. Use -999 to express null.
5 | Alphanumeric value. Mandatory. Correctness of measurement. J is interpreted as correct all other values are interpreted as incorrect. In Redbex an incorrect measurement is stored as erroneous observation.

Table 3: Description of the first 5 cells cells in a data GVR line

If the header of the GVR file specifies that the file contains time the last 8 characters of the line are interpreted as time (format hh:mm:ss).

The data between the 5th cell and the time (or the end of line if no time is given) is interpreted as standard command and free comment. The standard comment is a comment that is interpreted by Redbex by matching that string against the Standard Comment Classification. If a (non-empty) free comment is found that comment will be added as observation comment in the observation's associated data. The standard comment is separated from the free comment by a single space. Maximum length of the standard comment is 25 characters.


Inclinometer

Last edited: 12/8/2017 7:40:32 AM

The inclinometer import type can be used to import data for the feature type Inclinometer.

Data | Notes
Feature Name | New features can be created automatically, observations for already existing features will be appended to that feature.
Type specific observation data | Depth, deviation in A, deviation in B, Zero-reading and Erroneous flag

Table 1: Data that can be imported by this import type

The file format expected by this import type is a text file structured in lines and columns. The text file can include Unicode characters encoded as UTF-8 (which is backward compatible to ANSI with codepage 65001). The file may use a BOM (Unicode byte order mark) to specify the byte order of the character encoding.

A line in the source file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Leading and trailing white space characters (see table 2) will be automatically trimmed from each line. If the column separator is set to tab (U+0009) tabs will not be trimmed. The first character of a line is defined as the first non-white space character, the last character as the last not white space character.

Lines where the first character is a # (U+0023, UTF-8: 0x23) are treated as comment lines and will be ignored. If the # is contained in a line but not the first character in the line it will be treated as data. Empty lines (after trimming) except the first non-comment line after the first header line are ignored.

Each non-comment and non-empty line is separated into cells by the column delimiter character. The column delimiter character can be set in the import type's settings. Only one column delimiter character is allowed between two columns, i.e. for n columns you need exactly n-1 column delimiters, and column n is the column after the n-1th column delimiter.

The first two non-comment and non-empty lines are treated as header lines. Header lines contain processing information for the import. The first header line is used to define the contents of each column by specifying a column content identifier in each cell. This column content identifier is used by the Application Server to match the data in that column to some characteristic of the inclinometer feature or observation. Columns with a column content identifier that is not recognized by the Application Server are ignored. The second header line is used to define the unit for numeric values if these numeric values are matched against a quantity property in the observation's type specific data property structure.

Table 2 shows the column content identifiers that must be present for this import type. Since the column headers in header line 1 define the contents of each column, the sequence of columns is not important

Column content identifier | Description
FEATURE | Identifying name of the inclinometer feature
OBSERVATION_SAMPLINGTIMESTAMP | Sampling timestamp of the observation
DEPTH | Depth of the observed value
A | Deviation in A
B | Deviation in B
ZEROREADING | Zero reading flag
ERRONEOUS | Erroneous flag

Table 2 column content identifiers that must be present for this import type

Figure 1: Example for an import source file used to import inclinometer data. Note the orange arrows show tabs.


%Text%

Navigation: Application Server > Content > Data import > Import types >

Interlab (Version 4)

Last edited: 3/9/2018 10:39:56 AM

Interlab is a file format for the transfer of analytical data between database systems, e.g. from water and food laboratories to other database systems. The initiative for the creation of file format was taken by the then Swedish Water and Waste Water Association, VAV (now Swedish Water) in the early 1990s. The first version was published in 1995. Redbex Supports Interlab version 4.0.

For a full documentation of the Interlab standard please refer to the original Interlab specification. This chapter discusses aspects of the Interlab that are relevant for understanding how Redbex will import data from Interlab files.

Syntactical aspects

File name

The Interlab Standard specifies that .lab is the only valid extension for Interlab files. Redbex however does not check the extension for Interlab files but inspects the file contents to check if the file is an Interlab file.

Text encoding

According to the Interlab standard Interlab files must be encoded using UTF-8, UTF-16 or UTF-32. The actual encoding used may optionally be specified in the header of Interlab files using the #Tecken control sequence. Redbex will not use this information in from the header of the Interlab files. Using the import settings you can either set the (expected) character encoding of the source files manually or leave it up to Redbex to detect the actually used encoding by inspecting Interlab files on a byte level. This approach is more reliable since the actual encoding of a file might easily change while the header of the Interlab file is probably not changed accordingly.

The character encoding detection built into Redbex is based on a port of the Universal Charset Detector of Mozilla. This charset encoding detection is able to detect the character encodings shown below

Detection of the character encoding is however in many cases non-deterministic, i.e. the character encoding of a file or a series of bytes can only be detected with a certain probability.

·UTF-8

·UTF-16 (BE and LE)

·UTF-32 (BE and LE)

·windows-1252 (mostly equivalent to iso8859-1)

·windows-1251 and ISO-8859-5 (cyrillic)

·windows-1253 and ISO-8859-7 (greek)

·windows-1255 (logical hebrew. Includes ISO-8859-8-I and most of x-mac-hebrew)

·ISO-8859-8 (visual hebrew)

·Big-5

·gb18030 (superset of gb2312)

·HZ-GB-2312

·Shift-JIS

·EUC-KR, EUC-JP, EUC-TW

·ISO-2022-JP, ISO-2022-KR, ISO-2022-CN

·KOI8-R

·x-mac-cyrillic

·IBM855 and IBM866

·X-ISO-10646-UCS-4-3412 and X-ISO-10646-UCS-4-2413 (unusual BOM)

·ASCII

Line

While not specified in the Interlab standard Redbex defines a line in an Interlab file as a sequence of characters followed by a line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Trimming lines

When reading Interlab files Redbex will ignore leading and trailing white space characters of each line in the file. White space characters are defined as shown in table 1.

Empty lines

When reading Interlab files Redbex will always skip any empty lines or lines that contain only white space characters (see table 1).

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).

Table 1: White space characters

Comment lines

The Interlab standard does not specify a possibility to add comments to an Interlab file. Deviating from the standard Redbex will interpret every line starting with a $ character as a comment line, and will therefore not parse this line.

Control sequences

Interlab files contain control sequences that advice the reading software product on how to read and interpret the data in the Interlab file. Control sequences always start with a # character followed by a sequence of characters. Control sequences are case insensitive.

Header

An Interlab file always contains a header. The header is a series of control sequences starting with the #interlab control sequence and ending at the first #provadm control sequence.

Data section

A data section consists of a provadm section and a provdat section. A valid data section must always have a provadm and a provdat section, one Interlab file may have multiple data sections. each provadm and provdat section contains one header line, and one or more data lines.

Each line is a sequence of semicolon separated cells of data. According to the Interlab standard the last data cell must also be terminated by a semicolon. Redbex will determine if the last cell is terminated by a semicolon by inspecting the first data line in the first provadm section of the file.

The first line in a provdat or provadm section is the header line, all following lines are data lines. The header line specifies which kind of data is to be found in the cells of the following lines. The type of data is specified in header lines by using strings that are defined in the Interlab standard. Redbex compares these strings case insensitive.

The number of data cells in the header line must match the number of data cells in each data line.

A provadm section starts with the #provadm control sequence a provdat section starts with the #provdat control sequence. The provadm section ends with the #provdat control sequence. The provdat section ends with the #provadm section of the next data section or with the #slut control sequence.

Semantic aspects

Feature name

Interlab uses the Lablittera cell to give each sample a unique id, however multiple samples may belong to the same Redbex feature, this association of sample IDs to features is not defined in the Interlab format. To still be able to import data from Interlab to Redbex, Redbex therefore uses the Specific provplats cell. This cell is optional according to the Interlab standard but Redbex defines it a mandatory and each line in provadm sections must have a non empty Specific provplats cell.

Null

Empty cells are considered as null. Cells containing only a single dash - are also considered as null cells.

Mapping of sample types to feature types

The data in Interlab formats is imported into features of different types according to the value of the provtyp cell in the provadm section setting. Table 1 shows the mapping of provtyp to feature types that is used by the import. The importer will compare the provtyp case-insensitive.

The import settings allow you to add additional provtyp identifiers for each supported feature type.

Provtyp | Feature type
Avloppsvatten Dricksvatten Grundvatten Ytvatten Dagvatten/dräneringsvatten Lakvatten Länshållningsvatten Processvatten Spolvatten Släckvatten Tunnelavloppsvatten | Water analysis
Sediment Slam Jord Bergkross Asfalt Betong Sulfidjord Industri och gruvslagg | Soil analysis
Porgas Övrig luft | Air Analysis

Table 2: Mapping of provtypes to feature types

Import settings

Setting

Description

General

Store soruce files

Coordinate system

Interlab files do not contain spatial information, however this setting can be used to create new features with the right spatial reference system

Create classification elements

If set the import will try to create missing classification elements.

Note that this is only possible if the user executing the import has appropriate permissions and if a classification is set as

Additional air ample types

Additional soil sample types

Additional water sample types

Localization

Character encoding detection

Defines how the import shall detect the encoding of the source files.

Automatic: The importer will try to detect the encoding of the source files automatically (and independently for each source file.)

Manual: The import will use the assume defined encoding of the Character encoding setting for each import file. Use this option if the automatic detection does not yield the wanted results.

Character encoding

Only used if Character encoding detection is set to manual

Table 3: Settings of the import type Interlab


TMO

Last edited: 4/16/2018 9:57:42 AM

TMO is a database system developed by Trafikverket. TMO is used to store data of various types amont them ground water data, surveying data and environmental data.

Note: The Redbex TMO import is implemented as a one-time-only import. I.e. the import is meant to be used to convert data from TMO databases to Redbex but not for regular updates of data from TMO to Redbex.

There are two slightly different version of TMO that are both supported by Redbex: Hasp and Regular Before importing the user has to define the dialect. The import procedure will then parse the data according to the selected dialect.

Preparing the TMO database

This only applies to TMO databases of dialect regular

Redbex imports data from TMO databases by directly connecting to these databases. However, TMO systems use a second independent database for Geographic data. To make this data available to the TMO import you must fist create views in the TMO database (typically called WebDB) that creates a bridge to the geographic data.

Listing 1 shows the SQL commands to create these views. Note that you have to change the script in order to match your database name.

CREATE VIEW ByggnadSpatial
AS
SELECT
[OBJECTID_1]
,[OBJECTID]
,[X_Centroid]
,[Y_Centroid]
,[Name]
,[ByggnadID]
,[area]
,[len]
,[SHAPE]
FROM [<Name Of Tmo GeoDB>].[dbo].[SBK_BYGGNADER]

CREATE VIEW DubbgrupperSpatial
AS
SELECT T1.SHAPE, T1.GruppNamn, T1.Grupp AS GroupId
FROM [<Name Of Tmo GeoDB>].dbo.DUBBGRUPPER_BYGGNAD T1
UNION ALL
SELECT T2.SHAPE, T2.GRUPP_NAMN, T2.GRUPP As GroupId
FROM [<Name Of Tmo GeoDB>].dbo.DUBBGRUPPER_KONSTRUKTION T2
UNION ALL
SELECT T3.SHAPE, T3.Grupp_Namn, T3.GRUPP AS GroupId
FROM [<Name Of Tmo GeoDB>].dbo.DUBBGRUPPER_MARK T3

Listing 1: Script for creating the views

Other buildings in the database

Since the TMO import is a one time operation, the TMO import does not update and existing buildings in the Redbex database.


Landmäteriet (Blocks/Lots/Buildings)

Navigation: Application Server > Content > Data import > Import types >

Lantmäteriet (Areas / Lots / Buildings)

Last edited: 3/8/2018 7:30:14 AM

This import type reads areas, lots and buildings from a GSD-Property Map database of the Swedish Lantmäteriet Organization and transforms them to features of type Landregister Area, <%TARGETTITLE%>, %Text% features. The features will be related to each other using platform relations according to the information found in the source database.

Additionally to creating new features an updating existing features, this import type will also modify features in Redbex that are not found in the GSD database. On those features the import will set the Obsolete property in the type specific data of the feature.

The import is always performed with a geographic filter, i.e. only those objects in the GSD-Property Map database will be handled by the import that fall within the provided filter-geometry and only those features in Redbex will be compared that fall within the provided filter-geometry.

Table 2 shows how the terms used in Lantmäteriet are translated to English in Redbex.

Setting

Description

General

Coordinate system

Mandatory

The coordinate system that is expected in the source database. Lantmäteriet uses EPSG 3006 as default. So you should have a matching projected coordinate system set up and select this coordinate system here.

Import region

Mandatory

Defines the region that defines which data will be imported from the GSD-Property map database and the import features in Redbex that will be used for matching during import

Block creation strategy

Defines how the importer shall form areas out of the provided lots.

If you want small blocks (kvarter), you should use the Block option. Same if the areas are getting very large.

Alias scheme for old building names

Mandatory

The old names of buildings that the importer renamed because the building could be matched by geometry will be kept as an alias in this scheme.

Advanced settings

Create classification elements

If set, the import will try to create missing classification element. Elements can only be created if the importing user has the appropriate permissions.

Geometry match for buildings

If set, the matching of buildings found in the GSD-Property Map database to already existing features of type TMO building will be done by name and - if no name match is found - by geometry. In this case a feature is a match if it's geometry matches more than 90% (i.e. if the Area of the intersection of the geometries is more than 90% of the area of the geometry in the GSD database).

This option only needs to be turned on if there are already features of type TMO building in Redbex that were imported from another source or created manually.

Table 1: Type specific import settings in group General for this import type.

English term | Swedish term
Lot | Fastighet
Block | Block
Area | Kvarter
Building | Byggnad
District | Trakt
Commnity | Kommun
State | Län

Table 2: Translation of terms used in the Lantmäteriet import


Preparing the source database

Last edited: 11/8/2017 8:41:38 AM

This import type uses a MS SQL Server database as its data source and utilizes the power of the database engine to speed up the data preparation. Therefore Before this import type can be used some preparation of the source database is needed.

The database that the import connects to must contain the source data, and the user connecting to that database must have the appropriate permissions to create and delete tables in that database as well as to read and modify all data.

Since it is usually not wanted that the import process changes the original GSD-Property Map database we recommend that the import connects to a working database which contains views or copies of the data in the original GSD-Property Map database. In the following we discuss different ways how data can be made available.

Making source data available via Linked Server and views

If the original GSD-Property Map database is not on the same database server as the database the import connects to you can create views to the FK_AY and FK_BY tables in the original database by first creating a Server Link and then creating the views using the commands shown in listing 1 and listing 2.

CREATE VIEW FK_AY

AS

SELECT *

FROM OPENQUERY(

[<ServerLinkName>],

'SELECT * FROM [<SourceDatabaseName>].[<Scheme>].FK_AY');

Listing 1: Creating the FK_AY view for a remote database

CREATE VIEW FK_BY

AS

SELECT *

FROM OPENQUERY(

[<ServerLinkName>],

'SELECT * FROM [<SourceDatabaseName>].[<Scheme>].FK_BY');

Listing 2: Creating the FK_BY view for a remote database

Making source data available via views

If the original GSD-Property Map database is on the same database server as the database the import connects to you can create views to the FK_AY and FK_BY tables in the original database using commands shown in listing 3 and listing 4.

CREATE VIEW FK_AY

AS

SELECT * FROM [<OriginalDatabaseName>].[<SchemaName>].FK_AY

Listing 3: Creating the FK_AY view for a local database

CREATE VIEW FK_BY

AS

SELECT * FROM [<OriginalDatabaseName>].[<SchemaName>].FK_BY

Listing 4: Creating the FK_BY view for a local database

Making source data available by copying data

A third way to make the data from the original GSD-Propert Map database is copying the data for the FK_AY and FK_BY tables to the database that the import will connect to. While this approach of course requires you to repeatedly copy the database to get all the latest changes it might speed up the import process (especially when the original GSD database is on a remote server)

Listing 5 shows an example how data can be copied with an SQL script from a Linked Server.

IF (EXISTS(SELECT *

FROM INFORMATION_SCHEMA.TABLES

WHERE TABLE_NAME = 'FK_AY'

AND TABLE_CATALOG = DB_NAME()))

BEGIN

  DROP TABLE FK_AY

END

Select * INTO FK_AY

FROM OPENQUERY(

[<ServerLinkName>],

'SELECT * FROM [<SourceDatabaseName>].[<Scheme>].FK_AY')

Listing 5: Creating the FK_BY view for a local database. Note that this script deletes and already existing table!

Database Permissions

During the preparation of data this import type creates tables in the database it connects to and after import it will delete these tables again. The accessing user therefore needs the appropriate privileges create and delete tables.

Cleaning up the database

After the import the import process will delete tables it created, in terms of an abnormal termination of the import it might however be that these tables are not cleaned up. If this situation happens all tables starting with RbTemp can be manually deleted.


Importing areas

Last edited: 3/21/2018 7:25:14 AM

GSD-Property Map database does not contain entities for areas, areas are dynamically created from the lots found in the GSD-Property Map database by grouping lots according to the Area creation strategy chosen in the type-specific import settings. Table 1 shows the available options and their effects on the creation of lots. The geometry of an area is calculated as the geometrical union of all lots that make up the area.

Strategy | Description
Community name + District name + Block name | This strategy in this list will create more blocks and is therefore better suited for densely populated areas. Technically this creates blocks by grouping lots like this GROUP BY LAN_KOD, KOMMUNKOD, KOMMUNNAMN, TRAKT, IIF(CHARINDEX(':', BLOCKENHET) > 0, SUBSTRING(BLOCKENHET, 0, CHARINDEX(':', BLOCKENHET)), BLOCKENHET)
Community name + District name | This strategy will create less but bigger blocks and is therefore better suited for rural areas. Group BY LAN_KOD, KOMMUNKOD, KOMMUNNAMN, TRAKT

Table 1: Block creation strategies

Which data from the source will be processed

The geometry of an area is the geometrical union all lots that make up that area. Only those lots are processed, that are intersecting with the given filter-geometry. It might therefore be that imported areas are smaller than the real world areas.

Naming of features in Redbex

Areas will be named depending on your selected Area creation strategy:

Strategy | Description
Community name + District name + Block name | <CommunityName> <District name> <Block name>
Community name + District name | <CommunityName> <District name>

Table 1: Naming of Importing areas features depending on the selected area creation strategy

How areas are matched against existing Redbex features

During the import the importer tries to match the areas in the GSD database (that are in the selected filter-geometry) to feature of type Landregister Area in Redbex. The importer will only try to find matches for features that are within the selected filter-geometry. The matching is done by comparing the name generated from the data in the GSD database to the feature name in Redbex.


Importing lots

Last edited: 3/21/2018 7:33:10 AM

GSD-Property Map database does not contain entities for lots, lots are dynamically created from the lot-parts found in the GSD-Property Map database by grouping lots-parts with the same FNR_FDS number. The geometry of a lot is calculated as the geometrical union of all lot-parts that make up the lot.

Which data from the source will be processed

The geometry of a lot is the geometrical union all lots-parts that make up that lot. Only those lot-parts are processed, that are intersecting with the given Import region. It might therefore be that imported areas are smaller than the real world areas.

How will lots be matched against existing Redbex features

During the import the importer tries to match the lots it finds in the source against the features of type <%TARGETTTITLE%> that already exist in Redbex. The importer will only try to find matches for features that are within the selected Import region. The matching is done by comparing the lot name generated from the data in the GSD-database to the feature name in Redbex (case insensitive comparison).

Naming of features in Redbex

Created lot features will be named with the FNR_FDS number that uniquely identifies the lot.


Navigation: Application Server > Content > Data import > Import types > Lantmäteriet (Areas / Lots / Buildings) >

Importing buildings

Last edited: 3/21/2018 7:23:36 AM


Data export

Last edited: 10/5/2017 11:51:12 AM

The Application Server supports exporting data of features and observations as well as data of other elements managed by the Application Server to files.


Export definition

Last edited: 10/5/2017 11:51:16 AM

Exports are based on export definitions. An export definition is basically a collection of settings that advice the Redbex Application Server what data shall be exported and how the data shall be exported. Each export definition is based on one of the supported export types.

Export definitions can be created on-the-fly or can be persisted as stored export definitions within a domain. On-the-fly export definitions are created and executed but the export definition itself is then not persisted. They are best used if you want to export specific data once. Stored export definitions are export definitions that are persisted on the Application Server. You will typically create stored export definitions when you intend to repeatedly execute that export definition or when you plan to automate export using a stored job definition.

An export definition consists of:

·The underlying export type

·Common Settings: Specification of settings common to all export types

·Type specific settings (1): Specification of settings specific to the chosen export type (see documentation of the used export type for details). Type specific settings (1) is a UConfiguration.

·Type specific settings (2): Specification of settings specific to the chosen export type (see documentation of the used export type for details).

·Specification of an observation filter (only available for specific export types)

·Settings for stored export definitions


%Text%

Navigation: Application Server > Content > Data export > Export definition >

Common settings

Last edited: 10/5/2017 11:51:10 AM

Common export settings are settings that are available for all export types. Common settings is a UConfiguration.

General settings

Table 1 shows all settings available in the General settings group of the common settings.

Setting

Description

File name template

The text template that is used for naming files created by the export. If no template is given the Application Server will automatically choose a file name based on the current date & time.

Characters that are not valid for Windows file names will be automatically replaced with an _ character.

Date time format

The format string used for date time values in the export file.

If format is syntactically invalid or missing the format d will be used

Default is f

Culture

The culture used for formatting numeric values, date time values etc.

Table 1: General settings

Output files

The files created when the export definition is executed can be stored in Output files. The Output files group of the Common settings UConfiguration configures this.

Setting | Description
Copy to output files | If set the export files will be copied to the Output-Files

Table 2: Settings in the Output-files group

FTP Publishing

The files created when the export definition is executed can be uploaded to an FTP server. The FTP Publishing group of the Common settings configures this.

Setting | Description
Publish to FTP | If set the Application Server will try to publish the generated files to the specified FTP server
FTP-Server | The address of the FTP server
Port | The port on which the FTP server listens
Passive | If set, passive FTP mode is used
Timeout | The timeout to use when communicating with the FTP server
Username | The username used to authenticate against the FTP server
Password | The password used to authenticate against the FTP server
Path | The Path on the FTP server where the export files shall be placed. You can use a text template for specifying the path.

Table 3: Settings for publishing exported files to an FTP server

Document folder publishing

The files created when the export definition is executed can be published as Features of type Document that is member of a Document Folder feature. I.e. you can publish the output of an export as feature within Redbex.

The Document folder publishing group of the Common settings configures this.

Setting | Description
Publish to document feature | If set, the Application Server will publish the generated files as document within the specified document folder feature.
Document folder feature | The document folder feature into which the export files shall be published
Use versioning | If set, and if a document feature with the same name as the new export file is already in the specified document folder the Application Server will publish the new file as new version of that document. If not set the new file will always be published as new document.

Table 4: Settings for publishing to a document folder feature


%Text%

Navigation: Application Server > Content > Data export > Export definition >

Settings for stored export definitions

Last edited: 10/5/2017 11:51:40 AM

Table 1 describes the settings that are available for persisting export definitions as stored export definitions.

Setting

Description

Name

The name of the stored export definition (mandatory)

Grouping path

An optional grouping path used for organizing export definitions

Private

A flag that defines if an export definition is private to the current user or visible and usable by all users.

Note that for persisting an export definition as a public export definition you need the permission Manage export definitions (21).

Domain

The domain that the stored export definition will be associated with.

Table1: Settings for stored export definitions


Export types

Last edited: 11/16/2017 5:35:34 AM

The Application Server provides several export types that are able to export specific data managed by the Application Server into a specific file formats.


Features & Observations as tabular format

Last edited: 10/5/2017 11:51:16 AM

This export type exports feature and observation data of a set of features of the specified feature type. It supports Microsoft Excel 2007/2010 (xlsx) and tabular structured text files as output formats. When using xlsx as output format this export type can also write to template files.

When executing an export of this type the the Application Server will automatically add the file extension .xlsx to the export file if the Output file type setting is set to Excel (2007/2010) and if the expanded file name template does not have the extension .xlsx. If no extension was specified in the File name template setting and Output file type is set to Tabular text the extension .csv , .tsv or .txt (depending on the selected separator) will be automatically added to the file name.

This export type produces simple two dimensional tables, i.e. one row for each exported observation. If the type specific observation data is a hierarchical property structure this export type can optionally flatten the property structure for a selected collection of the type specific data.

Type specific settings (1)

Table 1 explains the settings available under Type specific settings (1) for this export type.

Setting | Notes
Feature type | Mandatory. Defines the feature type for this export. Only data of features of this type will be exported.
One file per feature | If set, the Application Server will create a separate export file for each feature.
Output file type | Specification of the file format that will be generated. ·Tabular text: Output will be a tabular structured text file. The export file will be a text file structured in lines and columns. Characters in this text are UTF-8 encoded. The line break is encoded as carriage return (UTF-8: 0x0D) immediately followed by a line feed (UTF-8: 0x0A) - the typical approach in Windows operating systems. ·Excel (2007/2010): Output will be in Microsoft Excel (version 2007 / 2010) format.
Column separator | Only applicable if output file type Settings for Tabular text format is selected. Specifies Column separator that will be used output files.
Null value | The string that will be written to the output file when exporting null values.
True value | Only applicable if output file type Settings for Tabular text format is selected. The string that will be written to the output file for logical True.
False value | Only applicable if output file type Settings for Tabular text format is selected. The string that will be written to the output file for logical False.
Classification elements output | Defines how classification values will be written to the output files: ·Name only: Only the name of the classification element will be written in the output file. ·Code only: Only the code of the classification element will be written in the output file. ·Name and code: Name and code of the classification element will be written to the output file.

Table 1: General group of the Type specific settings (1) UConfiguration for this export type

The group Feature data in Type specific settings (1) defines what feature data will be exported. Table 2 describes each setting in this group.

Setting | Notes
Feature name | If set the feature name will be written to the output file.
Approval status | If set the feature approval status will be written to the output file.
Export top level properties | If set the values of the feature-types top level properties will be written to the output file.
Top level properties | Only applicable if Export top level properties is set Defines which top level properties of the feature's type specific data shall be exported.
Export feature attachments | If set the attachments to the feature will be exported. In this the attachments will be copied and placed to the output location of the export. The file names of the attachments will be written to the tabular export file.
Attachment filter type | This setting can be used to filter the attachments to be exported. ·No filter: All attachments will be exported ·Tag filter: Filter by attachment tag ·Name filter: Filter by attachment name
Tag | Only applicable if Attachment filter type is set to Tag filter. Sets the tag that is used for filtering attachments. Only attachments with this tag set will be exported.
File name filter | Only applicable if Attachment filter type is set to Name filter. This is a regular expression that is used for filtering attachments by their original file name.
Include features without observations | If set also features that do not have any observations will be exported.

Table 2: Feature data group of the Type specific settings (1) UConfiguration for this export type

The group Observation data in Type specific settings (1) defines what observation data will be exported. Table 2 describes each setting in this group.

Setting | Notes
Sampling timestamp | If set the sampling time stamp of observations will be written to the output file.
Approval status | If set the approval status of observations will be written to the output file
Erroneous state | If set the erroneous status of observations will be written to the output file
Observation sensor | If set the name of the sensor used for recording this observation observations will be written to the output file
Export top-level properties | If set top level properties selected in the Top level properties setting will be exported.
Top level properties | Only applicable if setting Export top-level properties is set. The top level properties to be exported.
Export collection properties | Only applicable if setting Export top-level properties is set. If set the properties of a single collection in the feature types type specific observation data will be exported.
Latest comment | If set the latest comment stored with the observation will be written to the export file.
Export observation attachments | If set the attachments to observations will be exported. In this the attachments will be copied and placed to the output location of the export. The file names of the attachments will be written to the tabular export file.
Attachment filter type | This setting can be used to filter the attachments to be exported. ·No filter: All attachments will be exported ·Tag filter: Filter by attachment tag ·Name filter: Filter by attachment name
Tag | Only applicable if Attachment filter type is set to Tag filter. Sets the tag that is used for filtering attachments. Only attachments with this tag set will be exported.
File name filter | Only applicable if Attachment filter type is set to Name filter. This is a regular expression that is used for filtering attachments by their original file name.

Table 2: Observation data group of the Type specific settings (1) UConfiguration for this export type

The group Spatial location in Type specific settings (1) defines if spatial data is exported and in which spatial system and reference system the data shall be exported. Redbex will apply the necessary transformations of spatial data on export.

Setting

Notes

Spatial sytem

Defines the spatial system type for the export.

·No spatial location: No spatial data will be written to the output

·Axis: Spatial data will be transformed to the selected axis reference system and will be written to the output file.

·Coordinate system: Spatial data will be transformed to the selected coordinate system and will be written to the output file.

Type specific settings (2)

Here you can specify the features to be exported and an export file template (only applicable if you selected Excel as the Output file type.

Features to be exported can either be specified directly or indirectly via views or container features. Generally only features that match the feature type defined in Type specific settings (1) will be exported. Container features that are not of the selected feature type will be expanded automatically, i.e. all contained features that match the selected feature type will be exported. When using Views all member features of the view that match the feature type defined in Type specific settings (1) will be exported.

When using Excel as Output file type the export template file can be specified. If no export template file is given the export will write data to a new (blank) excel file on whenever it is run. If a template file is given the export will make a copy of this template and will write to that copy. I.e. you can prepare an excel file with your custom formulas, charts etc. and the export will just write new data to that file every time it is executed.

When a template file is used the export will write data to the first non-protected sheet in the excel file (starting with cell A1).

Observation filter

This export type provides the possibility to use an observation filter in order to limit the number of observations to be exported.

Additional Information about Excel files

Excel has limited support for date time values and for formatting date time values. Date time offset values will therefore be be converted to date time values when writing to excel files. Date time values will be written to Excel files in the format yyyy-MM-dd hh:mm:ss .

Boolean values will be exported as numeric 1 for True and numeric 0 for false.


%Text%

Navigation: Application Server > Content > Data export > Export types >

Ground water level as GVR

Last edited: 12/8/2017 7:40:24 AM

GVR is a text based file format for transferring water table data originating from a software product called Autograph. The GVR format has changed over the years and there is no official documentation on the exact syntax of GVR. For a deatiled explanation of the GVR format written by Redbex pleas refer to the GVR Import chapter.

Redbex is able to export data from feature of type Ground Water Level int GVR files. Each feature will be exported to a separate file. Note that GVR files shall be named as the Ground Water Level for which it contains data, use the {{FeatureName}} text template variable in the file name template configuration of the General Export definition.

The GVR Export format does have any type specific export settings.


%Text%

Navigation: Application Server > Content > Data export > Export types >

Users as tabular text

Last edited: 10/5/2017 11:51:44 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


View Members as tabular text

Last edited: 10/5/2017 11:51:16 AM

This export type writes some basic data of features that are member of a specified view to a tabular text file. Only the feature data that is readable with the feature permission List features (2) will be exported.

The export file will be a text file structured in lines and columns. Characters in this text are UTF-8 encoded. The line break is encoded as carriage return (UTF-8: 0x0D) immediately followed by a line feed (UTF-8: 0x0A) - the typical approach in Windows operating systems.

Table 1 shows the type specific settings for this export type.

Setting | Notes
Source view | The view whose member features will be exported. If the view is non executing no data will be exported.
Column separator | Column separator used in the output file

Table 1: Type specific settings for this export type.


Approval

Last edited: 12/4/2017 7:41:34 AM

The Application Server provides the possibility for users to approve the data of features and observations this of course also includes the possibility to deny approval of features or observations.

Approval processes in Redbex are user definable multi-user, multi-stage processes, that are instantiated for features or a set of observations belonging to a feature with the aim to approve or deny the data of features or observations. Features or observations for which an approval process has been started are protected against data modification.

Running approval processes are called Approval workflows in Redbex; they are created based on approval templates. Each workflow can be used to approve or deny a single feature or a set of observations belonging to the same feature. Approval workflows cannot be started for calculated features.

Approvals are meant to be the pendant to signatures on printed reports, but you have to decide yourself if the approvals you do within Redbex are in any way legally binding. Depending on the approval process security defined through the approval template, different security levels can be reached.


Approval status

Last edited: 10/5/2017 11:51:04 AM

Each feature and each observation has an approval status that specifies how reliable or complete the data of this feature or observation is. Table 1 lists the approval status available. The initial status for newly created features and observations is always In progress.

Setting the of a feature to Ready will automatically set the editing status of all observations that are currently in status In progress to Ready. I.e. if a feature is in editing status ready the data of the feature including the observations is believed to be complete and correct.

Since setting the editing status of a feature to Ready modifies the feature and it's observations this operation needs the feature permissions Modify (1) and Modify observations (4) on the feature.

Setting the editing status of a feature to In progress will not change the editing status of the feature's observations. Therefore this operation needs only Modify (1) permission on the feature. The approval status of a feature or observation can only be set to In progress if there is no active approval workflow for that feature. I.e. if the current status is Ready.

Table 2 summarizes the influence of approval status on actions that can be performed on features. table 3 summarizes the influence of the approval status on actions that can be performed on observations.

Status | Description
In progress | The data of the feature or observation is not yet complete.
Ready | The data of the feature or observation is complete
In approval | An approval workflow was initiated but is not yet finished
Approval aborted | The latest approval workflow was aborted
Approval denied | The latest approval workflow was closed with status Approval denied
Approval expired | The latest approval workflow was closed with status Approval expired
Approved | The latest approval workflow was closed with status Approved

Table 1: Approval status for features and observations

Action | In progress | Ready and above
Modify feature data |  |
Delete feature |  |
Create observation |  |
Delete observations |  |
Recall observations |  |
Modify observations |  | Implicitly through observations' status
Change spatial system |  |
Change feature subtype |  |
Purge observations |  |
Modify privileges |  |
Modify Feature PSC |  |
Modify Observation PSC |  |
Set feature spied |  |
Modify observation monitoring definitions |  |
Start approval workflows for observations |  |

Table 2: Effects of the feature approval status

 | In progress | Ready and above
Modify observation data |  |
Delete observation |  |
Recall observation |  |
Start approval workflows for observations |  |

Table 3: Effects of the observation approval status


Approval status transitions for features

Last edited: 10/5/2017 11:51:04 AM

Following transitions (changes) from one Approval Status to another are possible for features. Table 1 shows an overview of possible transitions.

1.In progress to Ready: Possible if feature permission Modify (1) and Modify observations (4) are given on the feature

2.Ready to In progress: Possible if feature permission Modify (1) is given

3.Ready to In approval: Automatically set when an approval workflow started

4.In approval to Approval aborted: Possible if feature permission Manage approval workflows (9) is given

5.In approval to Approval denied: Automatically set if some user denies approval

6.In approval to Approval expired:Automatically set if some approval stage expired

7.In approval to Approved: Automatically set if all stages were approved

8.Approval aborted to In approval: Aborted workflows are automatically set obsolete, therefore a new workflow can be started.

9.Approval denied or Approval expired to In approval: Possible if the active Approval workflow is set obsolete.

10.Approved to Ready: Possible if the active Approval workflow is set obsolete. Needs feature permission Manage approval workflows (9)

11.Approved to Approved but erroneous: Possible if the active Approval workflow is set erroneous.

12.Approved but erroneous to Ready: Possible if the active Approval workflow is set obsolete. Needs feature permission Manage approval workflows (9)

13.Approval aborted to Ready: Possible if the user has feature permission Modify (1)

To From | In progress | Ready | In approval | Approval aborted | Approval denied | Approval expired | Approved | Approved but erroneous
In progress |  | 1 |  |  |  |  |  |
Ready | 2 |  | 3 |  |  |  |  |
In approval |  |  |  | 4 | 5 | 6 | 7 |
Approval aborted |  | 13 | 8 |  |  |  |  |
Approval denied Approval expired |  |  | 9 |  |  |  |  |
Approved |  | 10 |  |  |  |  |  | 11
Approved but erroneous |  | 12 |  |  |  |  |  |

Table 1: Possible transitions of approval status for a feature.


Approval status transitions for observations

Last edited: 10/5/2017 11:51:04 AM

Following transitions (changes) from one Approval Status to another are possible for observations. Table 1 shows an overview of possible transitions.

1.In progress to Ready: Possible if feature permission Modify observations (4) is given on the feature

2.Ready to In progress: Possible if feature permission Modify observations (4) is given

3.Ready to In approval: Automatically set when an approval workflow started

4.In approval to Approval aborted: Possible if feature permission Manage approval workflows (9) is given

5.In approval to Approval denied: Automatically set if some user denies approval

6.In approval to Approval expired:Automatically set if some approval stage expired

7.In approval to Approved: Automatically set if all stages were approved

8.Approval aborted to In approval: Aborted workflows are automatically set obsolete, therefore a new workflow can be started.

9.Approval denied or Approval expired to In approval: Possible if the active Approval workflow is set obsolete first. Needs feature permission Manage approval workflows (9)

10.Approved to Ready: Possible if the active Approval workflow is set obsolete first. Needs feature permission Manage approval workflows (9)

11.Approved to Approved but erroneous: Possible if the active Approval workflow is set erroneous.

12.Approved but erroneous to Ready: Possible if the active Approval workflow is set obsolete. Needs feature permission Manage approval workflows (9)

13.Approval aborted to Ready: Possible if the user has feature permission Modify observations (4)

To From | In progress | Ready | In approval | Approval aborted | Approval denied | Approval expired | Approved | Approved but erroneous
In progress |  | 1 |  |  |  |  |  |
Ready | 2 |  | 3 |  |  |  |  |
In approval |  |  |  | 4 | 5 | 6 | 7 |
Approval aborted |  | 13 | 8 |  |  |  |  |
Approval denied Approval expired |  |  | 9 |  |  |  |  |
Approved |  | 10 |  |  |  |  |  | 11
Approved but erroneous |  | 12 |  |  |  |  |  |

Table 1: Possible transitions of approval status for observations.


Approval template

Last edited: 11/8/2017 9:24:20 AM

An approval template is the blueprint for approval workflows that can be created for a feature or a set of observations with the aim to approve them or deny approval for them. Approval templates are defined in domains and are propagated downward in the domain tree, i.e. if an approval template is defined for a specific domain it is available in all of its subordinate domains.

The approval templates available for defining the Template assignment in a specific context is defined by the domain of the context.

To create or edit approval templates you need the domain permission modify approval templates. Approval templates can be read by any user who has read permission on the domain the template belongs to.

The Application Server only allows to save valid approval templates, i.e. templates that have a name, at least one stage and at least one obligation in each defined stage.

Approval stages, obligations and fulfillment criteria

Each approval template defines a number of approval stages, at least one approval stage must be defined for each approval template, there is no limit on the number of stages. Approval stages have a specific sequence in which they will be conducted when an approval workflow is created out of the approval template. Within each stage the approval template defines the users and/or user groups that shall approve (or deny approval). These users or user groups then have approval obligation within this stage of the approval template. The approval obligations within a stage can be fulfilled by the users in any sequence.

Each stage has a stage fulfillment criteria. The stage fulfillment criteria defines how many users with the approval obligation have to actually approve for the stage to be closed. This allows you to implement a rule like 'at least 2 users out of a user group A have to approve in this stage'.

Note that when an approval workflow is created based on an approval template the user groups that have obligation for a stage in the template are expanded to the members of this group - therefore the fulfillment criteria really defines the number of users that have to approve.

An approval stage in an approval workflow derived from a template will be considered as closed as soon as the stage fulfillment condition is satisfied.

If the fulfillment criteria is set to zero all users with obligation have to approve, if set to a number greater zero this number of users have to approve for the stage to be closed. When an approval workflow is created based on an approval template the Application Server will check if the fulfillment criteria is greater than the number of obligations and in that case will automatically reduce the fulfillment criteria to the number of users with approval obligation.

Every approval stage also defines the settings for approval time span and automatic approval. See below for details.

Approval security

Each approval template defines the level of approval security it requires. This level defines the actions a user has to take when he wants to fulfill an obligation in a stage of an approval workflow. The available security levels are listed in Table 1.

Approval security level | Description
Simple | The user can approve an object with out any further action.
Password | The user has to provide his user password to approve the object.

Table1: Approval template security settings

Automatic Approval and expiration

Every stage in an approval template can define an approval time-span for this stage. Together with the setting for automatic approval that is also defined with each stage this provides the possibility to automatically approve a stage if users do not approve in the defined time-span, or to automatically close the workflow with approval denied if users did not fulfill their obligations within this time-span.

Whenever a new stage is started within an approval workflow the timestamp of the stage start is recorded. If the approval process template the workflow was created from defines a approval time-span for the stage the user with approval obligation in that stage stage can approve (or deny approval) till StageStartTime + ApprovalTimeSpan.

If after StageStartTime + ApprovalTimeSpan the stage's fulfillment criteria is not satisfied it depends on the auto approval setting of the stage how the system handles this expired stages. If auto approval is active for that stage the approval status for each approval obligation is set to automatically approved, else the approval process will be closed with status approval denied.

The Application Server will automatically search for expired approvals in intervals of 30 minutes. I.e. you might see an approval obligation or an approval workflow that is slightly overdue but not yet marked as expired.


Approval template assignment

Last edited: 12/6/2017 7:24:50 AM

The Approval template assignment specifies which approval template will be used to spawn an approval workflow for a specific feature or the observations of a specific feature. I.e. Approval template assignments link Approval templates to features.

Assignments are created as feature directives. Changing the assignment does not influence already started approval workflows in any way.

Table 1 lists the settings that can be made in an approval template assignment.

Setting | Description
Approval template for features | Defines the approval template to be used for features in the scope of the directive,
Approval template for observations | Defines the approval template to be used for observations in the scope of the directive.
Auto start approvalS workflows for features | If set, the approval workflow will be automatically started as soon the Approval status of a feature in this context is set to Ready.
Auto start approval workflows for observations | If set, the approval workflow will be automatically started as soon the Approval status of an observation in this context is set to Ready.

Table 1: Settings in an approval template assignment


Approval workflow

Last edited: 10/5/2017 11:51:04 AM

The instance of an approval template is called an approval workflow. Approval workflows are always created based on an approval template but are not linked to that template. I.e. changes to the approval template at a later point in time will not effect approval workflows that were created from this template.

An approval workflow is created either for a single feature or of for a set of observations belonging to the same feature, with the aim to approve this feature or this set of observations.

Conducting the workflow for a set of observations will either approve all observations or deny approval for all of these observations. Although one workflow can only approve a single feature the Application Server allows to start multiple workflows based on the same template for a given set of features.

A feature or an observation can be handled by any number of approval workflows, but only one approval workflow can be active at one specific point in time, all other workflows for that feature or observations are obsolete. An approval workflow in a final state can be marked as obsolete by users with the feature permission set approval inactive. An approval workflow is running when it is not in a final approval state, else it is closed.

An approval workflow can be created only for features or sets of observations where the Approval status of the feature is Ready or the Approval status of every observation in the set Ready.

As soon as a active approval workflow exists for a feature or observation the Approval status of this feature or observation cannot be set back to In progress. Therefore as long as there is an active approval workflow for a feature or an observation data for this feature or observation cannot be changed.

The creation of an approval workflows for features and observations is triggered manually.If the feature or observation has an assigned approval template and if that assignment is marked as auto starting that template will be used to automatically create an approval workflow as soon as a user sets the approval status of the feature or observation to Ready. If the assignment is not marked as auto starting the approval workflow can be instantiated manually.

Every user with the feature permission modify permission on the feature or the permission modify observations on the observations feature can set the Approval status to ready and can start an approval workflow.

Within an approval workflow the approval (or the denied approval) of every user with approval obligation is recorded. When a user denies approval the system forces the user to add the reason for denial as comment.

While obligations can be set to user groups in the approval process template an approval workflow will have only obligations for users. Therefore at the time of creation of the workflow the system will evaluate the group members and define obligations for each member of the group. Therefore that later changes to group members will not affect already created approval workflows.Approval workflows can only be created if the obligations in each stage of the approval template define at least one user who gets approval obligation.

Workflow characteristic | Description
Active | This workflow defines the approval status of the feature or observation it was created for. there can be only one active workflow for each feature or observation.
Obsolete | A workflow that was conducted in the past but does not define the status of the feature or observations it was created for.

Table 1: Summary of active and inactive workflow characteristic.

Workflow characteristic | Description
Running | An active workflow that is not in a final state
Closed | A workflow, either active or inactive, in a final workflow state

Table 2: Summary of running and closed workflow characteristic.

Within a stage users can handle their obligations (approve or deny) in any sequence. If one user denies approval in a stage the whole approval workflow is closed with status approval denied.


Approval workflow status

Last edited: 10/5/2017 11:51:04 AM

Approval workflows are always in a specific status. If the workflow is active this state of the workflow is also the Approval status of the features or observation this workflow was created for. Figure 1 shows a state diagram of an approval workflow.

Table 1 gives a short description on the meaning of the states. The states Approval denied, Approved, Approval aborted and Approval expired are final states i.e. if the workflow is in one of those states the Approval workflow is closed.

State name | Description
In approval | One stage of the approval workflow is currently waiting for approval of users.
Approval denied | A user has denied the approval of the object.
Approved | All approval conditions in each stage of the process have been fulfilled
Approval aborted | The approval process was forcefully closed unapproved.
Approval expired | The approval process expired

Table 1: Description of approval stages

Figure 1: State diagram of the approval process.


Approval obligation status

Last edited: 10/5/2017 11:51:04 AM

Each approval obligation in a stage of an approval workflow is always in a specific approval obligation status. Table 1 list the possible states together with a description.

Approval obligation state | Description
Assigned | The obligation is assigned to a user but the user did not yet handle this obligation
Approved | The user approved and therefore fulfilled his obligation
Approval denied | The user denied approval and therefore fulfilled his obligation
Approval not needed | If stage fulfillment criteria is fulfilled by other approved obligations the approval obligation state for the users whose approval therefore is not needed
Automatically approved | The user did not approve within the approval time-span and auto approval setting was on
Automatically denied | The user did not approve within the approval time-span and auto approval setting was off

Table 1: Approval obligation status


Aborting approval workflows

Last edited: 10/5/2017 11:51:02 AM

There might be cases when you want to close an approval workflow that is still running. For example this might happen when a user who has obligation in some running approval workflow is not available any more or if during an approval workflow new data became available and shall be stored.

The Application Server allows users with the feature permission Manage approval workflows (9) to abort a running workflow. The workflow is then set to status Aborted. Aborting an approval workflow will automatically also make this workflow obsolete,


Obsolete workflow

Last edited: 10/5/2017 11:51:30 AM

A feature or an observation can be handled by any number of approval workflows, but only one approval workflow can be the active approval workflow. To create a new workflow on a feature or on observations that were already handled by another approval workflow this already existing workflow has to be marked as obsolete. Obsolete workflows are kept in the system for traceability reasons but they do not define the feature's or observations' approval status.

To mark an approval workflow as inactive the user has to have the feature permission Set approval obsolete (10). Only closed approval workflows can be set obsolete. Running workflows have to be aborted first.

If a feature's or observations' Approval workflow is marked obsolete the Approval Status of the feature or observation will be set to Ready.

The Application server will store who set the workflow to obsolete.


Erroneous approval workflows

Last edited: 10/5/2017 11:51:14 AM

Even if an approval workflow is closed with status approved and the feature or the set of observation the workflow was created for is therefore considered as approved, it is possible to at a later point in time the approved data is found to be erroneous.

Revoking an approval is not possible since other persons or systems could have already made decisions based on the approved data and there is no guarantee that a revocation would be published to all of these persons or systems. But to document this specific situation the system provides the possibility to mark a closed approval with approval status approved as erroneous and to store an erroneous approval comment.

Marking an approval workflow erroneous does not automatically mark it as obsolete. To mark an active approval workflow as erroneous the user must have previously approved the workflow.

The Application server stores who marked the workflow as erroneous.

Even if the workflow is marked erroneous the Feature or observations it was conducted for will stay in Approved state. Marking a workflow as erroneous is really just a informative flag.


Connectors

Last edited: 10/5/2017 11:51:12 AM

Connectors provide the possibility to access data stored and managed in external software systems through Redbex. I.e. connectors allow you to work with data stored in other software systems as if it was data stored in Redbex itself.

Connectors only allow read access, I.e. observation data read via a connector cannot be modified.

When creating a new feature the feature can be created with data source connector. Doing so the Application Server will create a feature together with a connector of a specific connector type. Different types of connectors allow you to connect to different external systems.

Using the connector data of the feature you can then configure the connector. Which configuration settings are available is defined by the connector type.

When using connectors Redbex relies on the speed and logic of the connected external system.


Observation Monitoring

Last edited: 10/5/2017 11:51:30 AM

The Application Server allows to monitor the observations as they are created or modified and can trigger actions whenever those modified observations fulfill some predefined rules. One prominent use for observation monitoring is sending out messages whenever an alarm condition is detected (also known as alarming), but observation monitoring goes beyond that.

Observation monitoring is based on observation monitoring definitions that can be created by the user. Observation monitoring definitions are specified with a specific feature context and therefore apply to all features in that context that are marked as being spied. See chapter enabling observation monitoring for more details.

An observation monitoring definition consists of tree main elements triggers, conditions and actions. Triggers are the events that cause rules to be checked triggers can be creation of new observations or modification of observations. Conditions are the rules that are checked whenever a trigger fires, they specify which characteristics have to be fulfilled by an observations for actions to be performed. Actions are the procedures that are carried out if a rule was fulfilled.


Enabling observation monitoring

Last edited: 10/5/2017 11:51:14 AM

Two preconditions have to be fulfilled for observation monitoring to be carried out for the observations of a specific feature. First, observation monitoring must not be globally disabled (see global setting Miscellaneous: Disable observation monitoring. Secondly a each feature whose observations shall be spied must be marked as being spied. Newly created features are marked as being spied by default.

An observation monitoring definition defined for a feature or a group of features will only be used if these two conditions are fulfilled.


Observation monitoring definition

Last edited: 10/5/2017 11:51:30 AM

Observation monitoring is based on an observation monitoring definitions that are can be created by the user.

Observation monitoring definitions are Feature Directives and will therefore apply to all features to which the directive applies. Any number of observation monitoring definitions can therefore be in place for a specific feature.

An observation monitoring definition specifies the triggers to which the definition will react, the conditions that will be checked and the actions that will be performed if the conditions match.

An observation monitoring definition is valid if it reacts to at least one trigger, has a rule with at least one term and has at least one action associated with it. Only valid observation monitoring definitions will be processed by the Application Server.

Each observation monitoring definition has an observation monitoring definition owner which is automatically set to the last user who modified the observation monitoring definition.


Observation monitoring permissions

Last edited: 10/5/2017 11:51:30 AM

Table 1 summarizes the permissions needed for modifying observation monitoring definitions according to the context they are defined for. Note that these permission only define who can create observation monitoring definitions. They are not checked before a specific observation monitoring definition is executed. I.e. if the permission to create a observation monitoring definition in a specific context is revoked from a user, the definitions the user created so far will remain active.

Table 2 summarizes the permissions needed for reading the observation monitoring definitions in different contexts.

Context | Needed effective permission
Feature | Observation monitoring (6)
Domain + feature type + feature subtype | <%DATADOMAINPERMISSION_OBSERVATIONMONITORING%> AND Observation monitoring (6)
Domain + feature type | <%DATADOMAINPERMISSION_OBSERVATIONMONITORING%> AND Observation monitoring (6)

Table 1: Permissions needed to create and modify observation monitoring definitions with different contexts

Context | Needed effective permission
Feature | Read (0)
Domain + feature type + feature subtype | Read (0)
Domain + feature type | Read (0)

Table 2: Permissions needed to display observation monitoring definitions with different contexts


Observation monitoring triggers

Last edited: 10/5/2017 11:51:30 AM

Creation and modification of observations are the triggers that can initiate the checking of observation monitoring rules. These triggers are mutually exclusive, i.e. whenever an observation is created only the creation trigger will fire, whenever an observation is modified only the modification trigger will fire.

Each observation monitoring definition defines to which triggers it will respond.

Whenever a observation is created or modified the system will check if observation monitoring is globally enabled and if observation monitoring is enabled for the feature the observation belongs to. If both of these conditions are true the system will search for all active observation monitoring definitions that respond to the creation or modification trigger and will initiate the checking of those rules.


Workflow

Last edited: 10/5/2017 11:51:46 AM

Figure 1 shows the decision workflow the system performs for observation monitoring whenever it detects a created or modified observation.

Figure 1: Decision workflow for observation monitoring


Observation monitoring conditions

Last edited: 10/5/2017 11:51:30 AM

The observation monitoring conditions stored with observation monitoring definitions are based on observation monitoring terms. The Application Server provides some basic terms that can be used and configured within a observation monitoring condition. Multiple terms can be added to one observation monitoring condition.

The observation monitoring condition will match on a specific observation if all of the terms in that condition match, i.e. the terms in the condition are combined by a logical AND operation.


Tautology

Last edited: 10/5/2017 11:51:42 AM

The tautology term will match any observation. It is useful if you want to create an observation monitoring definition that will trigger actions whenever an observation is created or modified.


Erroneous

Last edited: 10/5/2017 11:51:14 AM

The erroneous term for observation monitoring rules can be used to define a condition that will only match for either erroneous or non erroneous observations.


Numeric property value

Last edited: 10/5/2017 11:51:30 AM

The numeric property value term for observation monitoring conditions will match observations where a defined numeric property on level 0 of the property structure in the observations type specific data is in the defined interval. Table 1 summarizes the settings available for this term.

Setting | Description
Property | The numerical property of the property structure used for type specific observation data that will be checked by this term.
Value from | Define an interval that is used to compare the observation's property value. If the observation's property value is within this interval the term will match. Note that both interval boundaries are inclusive. ValueFrom ≤ ObservationPropertyValue ≤ ValueTo If the property value is null, this condition will not match.
Value to

Table 1: Settings for the numeric property value term


Quantity property value

Last edited: 10/5/2017 11:51:32 AM

The quantity property value term for observation monitoring conditions will match observations where a defined quantity property on level 0 or the observations' type specific data is in the defined interval. The comparison respects different units. Table 1 summarizes the settings available for this term.

Setting | Description
Property | The quantity property of the property structure used for type specific observation data that will be checked by this term.
Value from | Define an interval that is used to compare the observation's property value. If the observation's property value is within this interval the term will match. Note that both interval boundaries are inclusive i.e. the rule will match if ValueFrom ≤ ObservationPropertyValue ≤ ValueTo If the property value is null, this condition will not match.
Value to
Unit | The unit in which Value from and Value to are given

Table 1: Settings for the quantity property value term


Boolean property value

Last edited: 10/5/2017 11:51:06 AM

The Boolean property value term for observation monitoring conditions will match observations where the value of a defined Boolean property on level 0 of the observations type specific data is either true or false. Table 1 summarizes the settings available for this term.

Setting | Description
Property | The Boolean property of the property structure used for type specific observation data that will be checked by this term.
Comparison value | True or false. If the property value is null, this condition will not match.

Table 1: Settings for the Boolean property value term


Observation monitoring actions

Last edited: 10/5/2017 11:51:30 AM

Whenever an observation monitoring condition is matched by a created or modified observation the observation monitoring actions associated with this observation monitoring definition are executed. Each observation monitoring definition can define any number of actions. The Application Server provides a set of action types that can be used and configured in a observation monitoring definition.


Send message

Last edited: 10/30/2017 2:12:38 PM

The message observation monitoring actions can be used to send messages to users. The message sender will be the observation monitoring definition owner. Table 1 lists the settings you have to specify for this action.

Setting | Description
Subject | Text template for the subject of the sent message If empty the Application Server will try to use the general text template
Body | Text template for the body of the message
User recipients | Users who will receive the message
Group recipients | Groups who will receive the message
Message severity | Message severity of the sent message

Table 1: Settings for the send message action

Besides the common variables the text template used for messages sent as observation monitoring action supports the variables shown in table 2:

Variable name | Description
monitoringDefinitionOwner.Username | Details of the user owning the monitoring definition that define this message.
monitoringDefinitionOwner.FirstName
monitoringDefinitionOwner.MiddleName
monitoringDefinitionOwner.LastName
monitoringDefinitionOwner.Id
monitoringDefinitionOwner.CellNumber
monitoringDefinitionOwner.EmailAddress
monitoringDefinitionOwner.Address
monitoringDefinitionOwner.FormattedUserName | Nicely formatted name of the currently accessing user.
PoolingInterval | The pooling interval for this action
FeatureId | Id of the feature for which the observation monitoring action was triggered.
FeatureName | Name of the feature for which the observation monitoring action was triggered.
ObservationSamplingTimestamp | Sampling timestamp of the observation for which the observation monitoring action was triggered.
ObservationmonitoringTrigger | Sampling timestamp of the observation for which the observation monitoring action was triggered.
ObservationmonitoringDefinitionName | Type of trigger that initiated this action (create or modify)
StandardBody | A preformatted message body. You can use this variable to quickly create a message body that will include the most relevant information about the observation monitoring definition and condition that initiated this action.
StandardSubject | A preformatted message subject. You can use this variable to quickly create a message subject that will include the most relevant information about the observation monitoring definition and condition that initiated this action.

Table 1: Text template variables additionally available for Send message actions.


Create observation alarm

Last edited: 10/5/2017 11:51:30 AM

Alarming, i.e. sending a warning of existing or approaching danger is a major issue when dealing with sensor data. Redbex uses observation monitoring for alarming. While the Send message action can be used to inform human readers about alarm conditions detected, the Create observation alarm action allows to record alarm conditions along with the affected observations over time.

The create observation alarm action can be configured to request acknowledgment for all alarms it creates. Table 1 lists the settings available for an create observation alarm action.

Every alarm that is created will be linked back to the observation monitoring definition that created the alarm. If the observation monitoring definition is deleted that link will be removed but the alarms will stay untouched.

If an observation monitoring definition that already initiated an alarm is modified the condition in that observation monitoring definition might be different than the condition that initiated the alarm.

Setting

Description

Severity

Severity of the created observation alarms. Can be one of 10 predefined severity levels.

Acknowledging user group

The user group that has to acknowledge this alarm, can be left empty to define alarms that need no acknowledgment.

Note that the acknowledgment obligation is assigned to all users that are member of that group at that point in time when the alarm was created.

Acknowledging time span

The maximum time span beginning from the creation of the alarm in which the alarm shall be acknowledged. Together with the automatically recorded creation time stamp this time span is used to calculate the Acknowledging deadline.

Alarms that are not acknowledged in this time span are considered as overdue acknowledgments. While it is possible to acknowledge alarms with overdue acknowledgments, the Application Server remembers the fact that the acknowledgment was not given within the acknowledging time span.

Setting this time span to a value of 0:0:0 will actually result in an unlimited acknowledging time span.

Pooling interval

This is the number of seconds in which consecutive alarms will be considered as a single alarm.

Table 1: Settings for the create observation alarm action


Trigger recalculation

Last edited: 10/5/2017 11:51:30 AM

Triggers the recalculation of the specified calculated features. Recalculation is executed as the owner of the observation monitoring definition.


Action pooling

Last edited: 10/5/2017 11:51:30 AM

Action pooling is a possibility that allows to limit the number of actions performed as a result of observation monitoring definitions. In many cases it is not wanted that the creation or modification of observations repeatedly triggers the execution of observation monitoring actions in a short time period. E.g. if you create an observation monitoring definition whose conditions match if a numeric property of the observation exceeds some defined interval and which will send a message whenever that condition matches, it might happen, that your mailbox is filled with hundreds or thousands of messages in a short time. With action pooling you can prevent this situation.

Action pooling is configured by a single setting the pooling time span. If an action shall be triggered but the last triggering of the same action (in the same observation monitoring definition) is not longer ago than the configured pooling time span the action will not be triggered again.

Action pooling is defined for each action in an observation monitoring definition. Example: You may define an observation monitoring action that creates a new alarm each time it is called (pooling time span = 0) or but sends out a maximum of one message per hour.


Observation Alarms

Last edited: 10/5/2017 11:51:30 AM

Observation alarms are created as a result of an create observation alarm action in an observation monitoring definition. They are stored alongside the observations that triggered the observation monitoring action.

While the monitoring actions like Send Message can be used to inform users about the fact that there is an existing or approaching danger, observation alarms are the historical records of encountered alarm conditions. The Application Server also implements an alarm acknowledging mechanism that can be used to requests users to approve that an alarm was handled somehow.

An observation alarm is always linked to the observation it was created for and to the observation monitoring definition and action it was created from. Note that when you change an existing observation monitoring definition that already triggered alarms the new monitoring definition's condition might not have triggered the alarm, still the existing alarms are connected to the now modified observation monitoring definition. Deleting an observation monitoring definition will not delete the alarms triggered by that definition.

Table 1 lists all the data stored for an observation alarm, the data is partly created automatically by the Application Server and partly created based on the settings of the create observation alarm action in the observation monitoring definition.

Item | Description
Created on | The date & time when the alarm was created
Severity | The severity of the alarm. This is one of ten predefined severity levels. The lower the severity level the less severe the alarm.
Title | The descriptive title of the alarm
Acknowledged by | If the alarm was acknowledged, the user who acknowledged the alarm.
Acknowledged on | If the alarm was acknowledged, the date & time when the alarm was acknowledged.
Acknowledging notes | If the alarm was acknowledged, additional notes (not mandatory) the user who acknowledged added.
Acknowledgement deadline | The date & time till when the alarm has to be acknowledged.
Acknowledgement obligations | A list of users and/or user groups who have the obligation to acknowledge the alarm

Table 1: Data stored with observation alarms


Acknowledging alarms

Last edited: 11/8/2017 9:27:18 AM

When an observation alarm is created (as a result of the observation monitoring action alarm) it must be created with acknowledgment obligations.

In the observation monitoring action create observation alarm the acknowledgment obligations are assigned to users and/or user groups. When an alarm is actually raise all specified users (including all members of the specified user groups at that specific point in time) are assigned an acknowledgment obligation.

If only user groups are obliged to acknowledge an alarm it can happen that when the alarm is raised those user groups do not have any members. In this case the alarm will not be raised.

An alarm is considered acknowledged if one of the obliged users actively acknowledges the alarm.

The observation monitoring action can also define the maximum time span in which users shall acknowledge an observation alarm. Observation alarms that are not acknowledged during that time are considered as overdue acknowledgments.

Observation alarms that need acknowledgment can be acknowledged by any user having acknowledgment obligation and by by users with the system permission Acknowledge all observation alarms (20). When acknowledging an observation the acknowledging user can add an acknowledging comment. This comment is immutable after acknowledgment.

As soon as one user has acknowledged an observation alarm the alarm is considered as acknowledged. Each observation alarm can only be acknowledged by one user.


Listing alarms

Last edited: 10/5/2017 11:51:28 AM

The Application Server allows listing of alarms using various filters. Note that it is up to the client which filters will be actually supported in the user interface. Table 1 gives an overview of the supported filter criteria, if more than one filter criteria is used the all of the criteria have to match.

Criteria | Notes
Acknowledged | Filters for unacknowledged, acknowledged or both
Acknowledgement required | Filters for alarms that need acknowledgement, regardless if they are already acknowledged or not.
Created after | Filters for observation alarms that were created after the specified date&time
Created before | Filters for observation alarms that were created before the specified date&time
Feature | Filters for observation alarms linked to a specific feature
Minimum severity | Filters for observation alarms that have a severity greater or equal the selected comparison severity
Maximum severity | Filters for observation alarms that have a severity less or equal the selected comparison severity
Observation monitoring action | Filters for observation alarms created by a specific observation monitoring action (being part of an observation monitoring definition)
Overdue | Filters for alarms that are not acknowledged yet, but the acknowledging deadline has already passed, of for alarms that are acknowledged but were already overdue when they were acknowledged.

Table 1: Supported criteria for filtering observation alarms


Deleting observation alarms

Last edited: 10/5/2017 11:51:12 AM

The Application Server provides the possibility to delete single alarms or all alarms of a feature. Note that if an observation or a feature is deleted all the alarms linked to it are also deleted.

To delete a single alarm or all alarms of a feature the user must have the feature permission Manage (7) on the feature that the alarm indirectly belongs to or if.


%Text%

Navigation: Application Server > Content >

Obervation Planning

Last edited: 10/5/2017 11:51:30 AM

Redbex supports the creation of observation plans, i.e. plans that define in which time intervals you expect how many observations for each feature in a set of features. A plan can be checked i.e. can be compared against the actual observations stored with features and the violations will be recorded.

Observation plans are configured as a Feature Directives an are therefore linked to features but can apply to member features of that feature as well. Observation plans can be defined for sets of features regardless of the feature type. If an observation plan applies to a feature with data source connector the plan will not check this feature.

Basically an observation plan defines time intervals and the minimum and maximum number of expected features in these time intervals. The time intervals can be defined either in Simple Or Expert mode.

When an observation plan is checked it will cont the number of observations in the defined time intervals and will record any violations found.

No matter how the time intervals are defined an observation plan will always only check observations prior to the current date and time. I.e. time intervals in the observation plan with a start date in the future will never be checked, time intervals with a start date in the past but an end date in the future will be used only by the Observation Plan Reminder functionality.


%Text%

Navigation: Application Server > Content > Obervation Planning >

Simple check intervals definition

Last edited: 10/5/2017 11:51:40 AM

In Simple Mode you select a repetition interval (see table 1) a start date and an end date. The Observation plan will then check all intervals where the end date of the interval is between the defined start and end date (inclusive).

The time intervals defined with the repetition interval is inclusive on the lower border and exclusive on the upper. I.e. a time interval 2015-01-01:00:00 to 2015-02-01:00:00 would include observations with a sampling time stamp 2015-01-01:00:00 or 2015-01-31:23:59 but would not include observations with a sampling time stamp 2015-02-01:00:00.

Example:

Selected repetition interval: Once a month

Selected start date: 2015-06-23 00:00

Selected end date: 2015-09-01 00:00

Resulting Check intervals (Note: left boundary is included right boundary is not included)

[2015-06-01 00:00, 2015-07-01 00:00)

[2015-07-01 00:00, 2015-08-01 00:00)

[2015-08-01 00:00, 2015-09-01 00:00)

Repetition | Notes
Once a year | Checks on every first of January at 00:00 (exclusive) and looks back 12 month.
Once a quarter | Checks on every first of April, July, October, January at 00:00 (exclusive) and looks back 3 month.
Once a month | Checks on every first of a month at 00:00 (exclusive) and looks back 1 month.
Once a week | Checks on every Monday at at 00:00 (exclusive) and looks back 7 days.
Once a day | Checks every day at 00:00 (exclusive) and looks back 24 hours.
Once an hour | Checks start of an hour (exclusive) and looks back 1 hour.

Table 1: Interval definitions in Simple mode


%Text%

Navigation: Application Server > Content > Obervation Planning >

Expert check intervals definition

Last edited: 10/5/2017 11:51:14 AM

In Expert Mode the end of time time intervals are defined using an Event Schedule. You can think of this end points of the time intervals as the points in time when you want to check the count of observations.

The start of each time interval is calculated by subtracting a fixed time span or a fixed number of months from the end of the interval. The time interval defined is inclusive on the lower border and exclusive on the upper. I.e. A time interval 2015-01-01:00:00 to 2015-02-01:00:00 would include observations with a sampling time stamp 2015-01-01:00:00 or 2015-01-31:23:59 but would not include observations with a sampling time stamp 2015-02-01:00:00.


%Text%

Navigation: Application Server > Content > Obervation Planning >

Checking of observation plans

Last edited: 10/5/2017 11:51:08 AM

When an observation plan is checked the Application Server will first get all features that the observation plan applies to (as defined by the applicability rule and applicability filter of the feature directive). The plan can only be evaluated if the user who initiated the checking has the feature permission Read observations (3) on each of these features.

For each time interval defined by the observation plan and for each feature the plan applies to the Application Server will then count the number of observations with a sampling time stamp in that time interval.

If the Only Approved flag is set for an observation plan only approved observations will be counted.

The Erroneous handling setting for an observation plan instructs the Application Server how to handle erroneous observations. The default setting is to count both erroneous and non-erroneous observations. However you can also specify that only erroneous, only non-erroneous observations are counted. Using this setting you may also define an observation plan that will identify too many erroneous observations as plan violations.

If the number of observations found in a time interval is not between the minimum and maximum specified by the observation plan, the Application Server will treat this as a violation of the observation plan. Violations for a plan will be stored associated with that plan. Each violation will record the feature where the violation occurred, the time span in which the violation occurred and the difference between the plan and the actual number of observations. This difference is a negative number if the number of real observations is less than the minimum specified by the plan or a positive number if the number of real observations is more that the maximum specified by the plan.

The checking of an Observation Plan is always done as a job. Whenever an observation plan is evaluated the Application Server will first delete the results of previous evaluations. As the plan gets evaluated all violations are found are stored with the plan, i.e. as long as the evaluation of the plan is not finished the results do not necessarily represent all violations.

The checking of an observation plans can be automated using a stored job definition of type Check Observation Plan.


%Text%

Navigation: Application Server > Content > Obervation Planning >

Observation plan reminder

Last edited: 10/5/2017 11:51:30 AM

An observation plan can be configured to remind users of likely plan violations in the near future.

When an observation plan is checked and all of the following conditions are true the observation plan treats this as a likely violation:

·The Reminder is activated on the Observation Plan.

·The observation plan defines a check interval that includes the current date, this time interval is called the current check interval.

·This check interval's end date is less than a user specified time span away from the current date.

·This check interval's end date is more than a user specified time span away from the current date

·The observation count for this interval is not fulfilling the observation plan

If all of the above mentioned conditions are met when this observation plan is checked, the Application Server will send a message to a defined user group to inform those users about the likely violation. A likely violation is not recorded as an observation plan violation.

Table 1 summarizes the observation plan settings

Setting

Description

Reminder active

If set the observation plan will check for violations in the current check interval and will send reminders if violations are found.

Minimum response time

A likely violation is only detected if the time span between the date when the observation plan is checked and the end date of the current check interval is greater than this value.

This setting helps you to prevent reminders that would be sent to users even though users would not have enough time to react till the end of the current check interval.

Maximum response time

A likely violation is only detected if the time span between the date when the observation plan is checked and the end date of the current check interval less than this value.

This setting helps you to prevent reminders that would be sent to users even though the end of the current check interval is far away.

Message subject template

A text template that is used for the subject of the messages sent to users in case a likely violation is found.

Message body template

A text template that is used for the subject of the messages sent to users in case a likely violation is found.

Message severity

The severity for the sent messages.

Varable name | Variable type | Description
ObservationPlan | Class | Exposes details of the observation plan that triggered sending a reminder.
ObservationPlanCheck | Class | Exposes details of the actual check of the observation plan

Table 2: Text template variables supported in Message subject and Message body for observation plan reminders

Variable name | Variable type | Description
Name | Primitive | Name of the observation plan
Description | Primitive | Description of the observation plan
SourceFeatureId | Primitive | Id of the feature on which the observation plan is defined
SourceFeatureName | Primitive | Name of the feature on which the observation plan is defined
ErroneousHandling | Primitive | Handling of erroneous observations in this observation plan.
OnlyApproved | Primitive | Defines if only approved observations are counted when checking this observation plan.

Table 3: Properties of the ObservationPlan markup class.

Variable name | Variable type | Description
CheckDate | Primitive | Date and time when the observation plan check was initiated
LikelyViolations | Collection | Collection of likely violations (LikelyViolation markup class)
ReminderIntervalBeginning | Primitive | Time stamp of the beginning of the time interval for which likely observations were checked
ReminderIntervalEnd | Primitive | Time stamp of the end of the time interval for which likely observations were checked.

Table 4: Properties of the ObservationPlanCheck markup class.

Variable name | Variable type | Description
FeatureId | Primitive | Id of the feature for which a likely violation was identified
FeatureName | Primitive | Name of the feature for which a likely violation was identified
Delta | Primitive | The delta calculated for the current check interval.

Table 5: Properties of the Violation markup class.


Structure

Redbex provides several possibilities to structure the content it handles. These structuring possibilities not only help to organize your data in a way you can quickly access it but are also basis for other system functions like permission evaluation.


Domains

Domains are used to separate content in the system according to the needs of the user. Domains are used to organize features, sensors, classifications, alias schemes and others more. Any content that is organized using domains can only be assigned to exactly one domain.

Domains are organized in a tree like structure - the domain structure. The propagation of content assigned to a specific domain is different for different types of content.


Root domain

Last edited: 10/5/2017 11:51:34 AM

The system predefines one root domain that is named Root by default and has special characteristics: The root domain cannot be deleted and each user has the permission to list subordinate domains of the the root domain. However one can rename the root domain, change permissions and set other properties of the root domain if either the system permission Domains: modify root is granted or if privileges are granted explicitly on the root domain

The root domain is the only domain that has no parent domain, in other words all user defined domains have a parent domain.


Domain path

Last edited: 10/5/2017 11:51:14 AM

Each domain must have a unique name within the set of domains that belong to the same parent domain. Therefore the domain path from the root domain to the specific domain is always unique. In the example structure shown in figure 1 the path of Domain A1.1 is Root domain\Domain A\Datadomain A1\DataDomain A1.1

Figure 1: Exemplary domain structure


Propagation of membership

Last edited: 10/5/2017 11:51:32 AM

We say a content is assigned to a domain if it is directly linked to that domain. Content is member of a domain if it is assigned to that domain or assigned to any of the domain's parents (in case of downward propagation) or one of the subordinate domains (in case of upward propagation).

The propagation direction is either upward or downward. Upward propagation means that if a content is assigned to a domain it is member of all parent domains. Downward propagation means that if a content is assigned to a domain it is member of all subordinate domains.

Features and Sensors are propagated upward in the Domain tree. I.e. a feature or sensor assigned to a specific domain is member of all parent domains of that domain.

If in the example domain structure shown in figure 1 a feature is assigned to Domain A. 1. it is member of the Root domain, domain A, and domain A.1. It is not member of domain A.1.1, Domain A.2 or domain B.

All other data except features and sensors assigned to domains is propagated downward in the domain tree. I.e. if some data is assigned to a specific domain it is also member of all subordinate domains of that domain.

If in the example domain structure shown in figure 1 an alias scheme is assigned to domain A, the alias scheme is member of domain A, domain A.1 and domain A.1.1. It is not member of the root domain, or domain B.

Figure 1: Example domain structure


Considerations for structuring

Last edited: 10/5/2017 11:51:12 AM

While in many cases the domain structure will reflect your project structure just because it is natural for data like axes, classifications etc. to change with projects you should carefully plan the structure of your domains.

Changing the parent of a domain and therefore restructuring your domain tree might not be possible in all cases as soon as features, and sensors are assigned to that domain.

Figure1: Example of a domain structure with 2 features

If your Application Server only manages a small amount of data it might be sufficient to assign all features, sensors and other data to the root domain. However if you plan to manage more data with the Application Server a well thought out domain structure is crucial. Thinking of domains as your projects and sub-projects might be helpful when planning the domain structure, however be aware that the Application Server also uses domains to define the availability of data like classifications, axes etc.


Features and domains

Last edited: 10/5/2017 11:51:18 AM

When a feature is created it is associated with a specific domain. It is not possible to change a features domain association at a later point in time.

The domain in which a feature was created is called the associated domain of that feature. All features associated with a specific domain or any of its subordinate domains are called members of that domain.

Domain assignment shall not be used mainly for structuring features but for defining the context in which the feature is placed. E.g. which classifications are available, which axes are available etc. is defined by the domain.


Identity domains

Last edited: 10/5/2017 11:51:22 AM

Identity domains are domains that enforce unique naming of Features of the same Feature type. I.e. no two Features that are member of the same identity domain and have the same feature type are allowed to have the same Feature name. The comparison of feature names in identity domains is case insensitive.

Since you might have features with the same name in different projects (e.g. the first observed house in project 1 might get the name House 01 as well as the first observed house in project 2) the system does not enforce unique naming by default. If however a domain is designated as identity domain the system enforces unique naming of all member features of the same feature type.

For defining a domain as being an identity domain the domain permission Modify (2) must be granted on that domain.

The identity domain of a specific feature is the last domain up the domain tree (including the associated domain of the feature) that is designated as identity domain.

If a non identity domain should be turned into identity domain the system will first check if all the member features (so all features assigned to this domain of any of its subordinate domains) of the same feature type are uniquely named, if not the domain cannot be turned into an identity domain.

Secondly the system will check if any domain on the path from the root domain to the domain to be changed is already an identity domain, if yes the domain cannot be turned into an identity domain.

If any of the sub domains of the domain to be changed is already an identity domain, the system will try to set those domains to non-identity domains, if it fails to do so (e.g. because of missing permissions) the domain cannot be set as an identity domain.

Examples: If in the structure shown in figure 1 it would not be able to set Domain A as an identity domain since there are two of type X with name AB123. In the structure shown in figure 2 Data Domain A could be set as identity domain since it has no two member having the same feature type and the same name

Figure 1: Example 1

Figure 2: Example 2


Available feature types

Last edited: 10/5/2017 11:51:22 AM

You can define which feature types are available within a domain, i.e. which feature types will be available for creating new features within a domain. Setting the availability of feature types on a domain will not influence visibility or existence of already existing features in that domain.

For a feature type to be available in a specific domain it must be available on all domains in the specific domains path, or the other way round if a feature type is marked to be not available in one domain it will not be available in that domain and all of its subordinate domains.

By default i.e. when a domain is created, all feature types are available.


Deleting domains

Last edited: 10/5/2017 11:51:12 AM

A domain can only be deleted if no feature or sensors are member of that domain. Note that this also applies to deleted (but not purged) features. Deleting a domain will also delete all subordinate domains.

For the deleted domain as well as for all subordinate domains following related data is also deleted:

·Alias Schemes

·Approval Templates

·Assigned Coordinate Systems

·Attachment Tag Aliases

·Axes

·Classifications

·Cross Section Outlines

·Used classification association

·Feature creation templates

·Feature Subtypes

·Hidden Feature Types

·Map file sets

·Presentation templates (Chart, Map view, Report, Axis Section Drawing)

·Privileges

·Property structure configurations

·Stored export definitions

·Stored import definitions

·View - Domain associations

If the domain to be deleted is used as the default domain focus in a user's profile the domain focus will be deleted from that user's profile


Views

Last edited: 10/5/2017 11:51:46 AM

With possibly tenth of thousands of features it is obvious that these features need to be organized in some way. Views and the view structure provide a extremely flexible way to organize huge amount of features in a way that is best suited to your needs.

The view tree is a hierarchical structure of views. A view can have a parent view and subordinate views. Views without a parent view are called root views. The depth of the view tree is not limited. The view path is the path you have to go to locate a specific view in the view tree beginning from a root view. Due to the tree structure there is only one unique path for each view.

A view defines its view members by specifying a filter that is applied to all features that are members of the view's parent view, or if the view is a root view to all features. Therefore the members of a specific view are evaluated by combining the filter definitions of each view along the view's path with a logical AND operation.

The result of the execution of a view is a set of features that are called the view members. The member features of a subordinate view is always a subset of the member features of its the parent view.

In the example view structure shown in Figure 1 the actual filter that defines the members of View 3.2.2 is (Filter for View 3) AND (Filter for View 3.2) AND (Filter for View 3.2.2).

Figure 1: Example of a view structure

There is only one view tree, and this view tree is basically the same for all users accessing the Application Server. However privileges and the possibility of hiding views might restrict visibility of parts of the view tree for specific or all users. Personal (subordinate) views might be added to the view structure by each user and are also only visible for this user.

In comparison to the tree structure you know from your operating system's file system the view approach of the Application Server differs fundamentally. There is no direct association between a feature and a view, only the filter defines which features are member of a view. This results in following characteristics:

·One feature can be member of any number of views

·Changing data of a feature (including comments, observations etc) might change its view membership, since view filters can be based on data of features and their observations.

·View membership can be dynamic with time. I.e. the view membership might change only because time passed.

Besides being a tool for structuring features, views are also used to assign privileges to the view members. Therefore the privileges can be as dynamic and flexible as the view membership.


View filters

Last edited: 10/5/2017 11:51:46 AM

Every view has a view filter. Together with the view filters of all views on a specific views path the filter defines the members features of the view. View filters are constructed by combining atomic view filter terms with combination nodes (logical operators) in a tree-like structure. See figure 1 for an example. There is no limit to the number of filter terms or combination nodes and there is also no limitation on the depth of the tree structure.

Figure 1: Example of a view filter tree structure. A, B, C, D are the atomic view filter terms, NOT OR and AND the combination nodes

Each view filter consists of a filter tree with exactly one root combination node. A combination node can have any number of subordinate combination nodes and/or filter terms. A combination node represents a logical operator. It can be configured to be an AND or an OR operator. Additionally it can be negated to form NOT AND and NOT OR operators.

In Figure 1 the root combination node is the NOT OR node, it has one subordinate combination node and two subordinate filter terms (C and D).

View filter terms can only be subordinate terms of a combination nodes. View filter terms are always leaf nodes within the tree structure, i.e. they cannot have any subordinate combination nodes or subordinate filter terms. Each term is of a specific predefined view filter term type. Each view filter term type may expose user configurable properties.

The actual view filter is built by evaluating the tree structure from the leaves to the root, therefore you can define the precedence of the term combination by structuring the tree accordingly. Figure 2 shows some examples of view filter tree structures and their logical equivalent.

Figure 2: Examples for view filters with their mathematical equivalents. Red framed combination nodes are deactivated nodes.

Figure 2:1 and 2:2 result in the same filter. Since there is only one filter term there is no difference if the combination node is configured as an AND or an OR combination node.

Figure 2:2 and 2:3 show the usage of the negation operator for a view filter with a single term. These two filters also result in the same filter. Since there is only one filter term there is no difference if the combination node is configured as an NOT AND or an NOT OR combination node.

Figure 2:5 and Figure 2:7 shows multiple terms beneath a single combination term. The combination node's logical operator will be applied to all of its subordinate terms. When the logical operator of the node is negated (figure 2:6, figure 2:8) the negation is applied after the combination.

Figure 2:9 and figure 2:10 show examples of more complex view filters. As you can see the actual filter is created bottom up i.e. from the leaf nodes to the parent. The tree structure defines the evaluation precedence.

Combination terms and nodes can be deactivated. Deactivated parts of the tree structure will not be included in the actual filter expression for the view. Figure 2:11 and figure 2:12 show the effect of deactivating parts of a view tree.

View filters always filter for features i.e. they always return a set of features. Since one feature can have many observations a filter term type that queries on characteristics of observations needs to define an additional criteria - the count criteria. The system supports following count criteria: All, Any and None. E.g. if a view filter contains a term that filters for features that have observations within a specific time span you can define if the feature is included in the resulting feature set if all, any or none observations are in that time span.

If the view filter term type queries for specific property values of a property structure that is stored for the feature or the feature's observations that property might also be contained in a property collection and therefore there might be more than one occurrence of the property. Accordingly view filter term types that query for properties also have a count criteria setting. View filter term types that filter on data of features that are related to the feature through one or more more a one to many relationship will always include the count criteria setting for each one to many relationship.

The Application Server will not allow to store views with an empty view filter. If you store an view definition with an empty view filter or with a view filter that has only one root combination node the Application Server will automatically replace the view filter with either a contradiction filter (if the view is a root view) or with a tautology filter (if the view is subordinate of another view).


Public, Personal views

Last edited: 11/8/2017 9:27:44 AM

Public views are views that are accessible (e.g. visible for the Client) by all users with the appropriate privileges.

The system allows each user to create personal subordinate views of public views to further filter features according to personal needs. Personal views have following characteristics:

·Personal views are only shown and can only be accessed by the user who created them.

·Personal views can have personal subordinate views but can never have public subordinate views.

·You cannot assign privileges to personal views.

·Personal views cannot be root views, i.e. a personal view must have a public vies in its view path.

Besides that a personal view has exactly the same possibilities and characteristics as public views. Personal views are deleted if the parent public view is deleted.


View visibility

Last edited: 10/5/2017 11:51:46 AM

The Application Server provides the possibility to define the visibility of views therefore of parts of the view structure. A view can be defined as being hidden or non hidden. Hiding views can be a comfortable way of clearing up the view structure without loosing the created views.

A view's visibility information is stored along with the view. Even when a view is hidden, the privileges defined for that view are still evaluated. Do not use view visibility if you want to prevent access to features, since it is totally up to the client how the visibility information is used.

A view's visibility can be defined globally (for all users) or for a single user. A view is visible if it is globally visible and visible for the current user. I.e. a view is hidden if it is hidden either globally or for the current user.

Setting a view's global visibility requires the view permission Modify view (0). The visibility for the current user can be set without any special permissions.


Non listing views

Last edited: 10/5/2017 11:51:30 AM

When you design your view structure you might create views that are only used as parent views for other views but are not intended to be used for accessing features directly. For this cases the view can be marked as non listing view. A non listing view will not evaluate its members directly but provides a filter statement that is then used together with the (listing) subordinate views of this view.

When a Client requests to list members of a view from the Application Server the Application Server will return an empty list if the view is non listing. However the view still has members and any privileges with transformable view permissions will still be applied to all member features.


View member caching

Last edited: 10/5/2017 11:51:46 AM

When the Application Server lists all features in a view the view's filter is executed and the results are returned. This is usually performed in a few milliseconds. However to know the views a given feature is member of the Application Server has to evaluate the filter in all defined views, which might of course take considerably longer depending on your amount of views, the complexness of the filter criteria in these views and the depth of your view tree.

Since querying all views a given feature is member of is done frequently when you base your feature permissions on views, the Application Server uses an in-memory cache.

The basic principle behind view member caching is that behind the scenes the view members are evaluated on specific events and when the Application Server then queries for members of a specific view then it does not have to execute the filter but uses the members it cached last time the filter was evaluated. This view members cache is only used for evaluating feature permissions. When you list the elements of a single view the Application Server will always execute the view filter of that view.

Of course this implies that (in rare cases) you might experience the situation that privileges for features that are defined on a view are not immediately propagated to the view members. Therefore the actual privileges a user has on a feature at a specific point in time are only as up to date as the cache. If you have features where this could be a security concern assign privileges directly to those features.

As with other caches the view member cache resides in memory but it is persisted if you shut down the application server.

The view members cache is automatically updated whenever a feature observations or a view is modified. Modifications to features an views cause an immediate update of the view member cache if the Application Server is not already running a view member cache update, else the update will be performed as soon as the currently running update has finished. For performance reasons modifications to observations will cause a delayed update, i.e. the system only remembers that an update is necessary but will perform the update when an internal caching timer elapses next. This timer elapses every 30 seconds.


View bookmarks

Last edited: 10/5/2017 11:51:46 AM

If you have a rich view structure with possibly hundreds of views, it might become tedious to navigate through the view structure every time to get to the few views that hold the features you are interested in. To save you some time the Application Server provides the possibility to create view bookmarks.

View bookmarks are a convenience feature for clients accessing the Application Server. They are simply links to a specific view that the client can show in a flat list for faster access. Of course even though the bookmarks are displayed differently, when selecting a view bookmark you are really selecting the view and the view members are evaluated the same way as if you would have selected the original view.

View bookmarks are only available for the user who created them i.e. they are personal. You can assign a name to a bookmark, if you do not the path of the bookmarked view becomes the name.

If a view is deleted all bookmarks pointing to this view will be deleted as well.


View ordering

Last edited: 10/5/2017 11:51:46 AM

The results of evaluation of a view's filter is a set of features, by default this set is ordered by the name of the features. For each view you can define the view ordering by specifying an order criteria an an order direction.

An order criteria defines what data is used for ordering. See table 1 for a description of all supported order criteria. The order direction can be ascending (default) or descending.

Ordering criteria | Description
Name | Alphabetical ordering by feature name. This is the default ordering (with ascending direction) that is applied if the user does not specify any custom order.
Latest change | Order is based on the time stamp of the latest change of the feature. The latest change is calculated as the latest change to feature data or observation data of any of its observations.
Creation date | Order is based on the timestamp of creation of the feature.
Feature type | Order is based on the name of the feature type, and then by the name of the feature. Order direction is applied to the feature type name, the feature names are always ordered ascending.
Axis position | This criteria is only useful for views containing features using an Axis reference system for defining its spatial location. Features will be sorted by offset 1 of the feature LSO.

Table 1: Order criteria supported by views.


Deleting a view

Last edited: 11/8/2017 9:27:44 AM

Deleting a view will automatically delete the view and all subordinate views of that view. It will also delete all bookmarks visibility settings and privileges defined on that view and all of its subordinate views.

Since features are not directly linked to views, member features of a view will not be deleted when the view is deleted.

If the views used in the definition of charts, maps etc. that definition will not be deleted but might become invalid or show different results.


%Text%

Navigation: Application Server > Structure > Views >

View - Domain association

Last edited: 10/5/2017 11:51:46 AM

Views are independent of domains. i.e. a view is not part of a domain and may have members from different domains. You can of course create views that use A Domain filter term to list only features that are member of a specific domain, but that is only an option and not a must.

However it might be beneficial in some situations to associate specific views with a domain for display purposes. I.e. the client showing domains and views might show only views associated with a specific domain. Therefore the Application Server supports storing associations between views and domains.

A view is associated with a domain if it is either directly associated with that domain or if the view is set to be associated with all domains.


Handling of deleted features and observations

Last edited: 10/5/2017 11:51:22 AM

When deleting features or observations they are actually marked as being deleted first and will be purged from the database at a later point in time. I.e. after deleting a feature or observation that feature or observation will stay in the Redbex Application Server Database for some time until it is finally purged.

For performance reasons the Redbex Application Server does not respect the deleted mark for features and observations when executing views. Therefore when executing a view features and observations marked as deleted but not yet purged from the database will still be used to determine the view members.


View filter term types

Last edited: 10/5/2017 11:51:46 AM

The Application Server provides a predefined set of view filter terms that can be combined to form a view filter. The following chapters describe each of these view filter terms and their properties in detail.


%Text%

Navigation: Application Server > Structure > Views > View filter term types >

Common

Last edited: 10/5/2017 11:51:10 AM

Common view filter terms filter features by inspecting either characteristics of features or characteristics of the feature's observations.


Approval status

Last edited: 10/5/2017 11:51:46 AM

This filter term type can be used to filter features based on the features' approval status or based on the approval status of the features' observations.

Setting | Description
Filter approval status of | Specifies if the filter uses the approval status of features or the approval status of observations
Match for | Defines the approval status for which is filtered.
Matching criteria | Only used if the the term filters for the approval status of observations: ·Any: Filter will match if any of a feature's observation is in the specified approval state. ·All: Filter will match if all of a feature's observation is in the specified approval state. ·None: Filter will match if none of a feature's observation is in the specified approval state.

Table 1: Settings for this view filter term type


Axis interval (dynamic)

Last edited: 10/5/2017 11:51:46 AM

This feature term type allows filtering for features that are located in a specific interval on an axis. The interval of interest is given by providing a feature of type Axis position feature a Start offset and an End offset. The actual boundaries of the interval of interest is calculated by getting the latest observation of the provided axis position feature and subtracting Start offset and End Offset from it.

This term will include also features with a feature type that has spatial support on observations. In that case the feature will be matched if any of the observations are located in the interval of interest.

Setting | Description
Axis position feature | The axis position feature that is used to get a position on the axis on which the dynamic interval is calculated. The selected feature also indirectly specifies the used axis reference system.
Start offset | The offset from the axis position defined by the Axis position offset, that defines the start position of the interval. The specified offset will be added to the axis position defined by the axis position feature.
End offset | The offset from the axis position defined by the Axis position offset, that defines the end position of the interval. The specified offset will be added to the axis position defined by the axis position feature.
Search in other reference systems of axis | The filter will only match for features that are located using the axis that is base for the specified Axis Reference System. However, using the Search in other reference systems of axis setting you can choose if the filter shall include only features that use the same Axis reference System as used for specifying the Interval of interest or that use any reference system on the same axis.
Search criteria | The Search criteria setting can be used to define how the filter shall handle features that are only partly included in the interval of interest. When set to Fully contained the filter will only match features where Offset 1 and Offset 2 of the LSO are both in the interval of interest. When set to Intersects this filter will match features where Offset 1 or Offset 2 of the LSO is in the interval of interest.

Table 1: Settings for this view filter term type


Axis interval (static)

Last edited: 10/5/2017 11:51:46 AM

This feature term type allows filtering for features that are located in a specific interval on an axis.

This term will include also features with a feature type that has spatial support on observations. In that case the feature will be matched if any of the observations are located in the interval of interest.

Setting | Description
Axis reference system | The filter will only match for features that are located using the axis that is base for the specified Axis Reference System.
Start offset | The axis reference system offset that defines the start position of the interval.
End offset | The axis reference system offset that defines the end position of the interval.
Search in other reference systems of axis | Using the Search in other reference systems of axis setting you can choose if the filter shall include only features that use the same Axis reference System as used for specifying the Interval of interest or that use any reference system on the same axis.
Search criteria | The Search criteria setting can be used to define how the filter shall handle features that are only partly included in the interval of interest. When set to Fully contained the filter will only match features where Offset 1 and Offset 2 of the LSO are both in the interval of interest. When set to Intersects this filter will match features where Offset 1 or Offset 2 of the LSO is in the interval of interest.

Table 1: Settings for this view filter term type


Axis reference system

Last edited: 10/5/2017 11:51:46 AM

This filter term type will filter for all features that use a specific Axis Reference System.

Setting | Description
Axis reference system | Specifies the axis reference system the feature must use to match the filter term.

Table 1: Settings for this view filter term type


Comment

Last edited: 10/5/2017 11:51:46 AM

The Comment text term type allows to filter features based on the the text written in comments on the feature or on the feature's observations.

Setting

Description

Use comment on

Specifies if the filter uses comments features or the comments of observations

Comparison operator

The comparison operator used, see Table 2 for details

Comparison string

The comparison string can be up to 4000 characters.

Matching criteria

·Any: Filter will match if any comment of the feature or the feature's observations (depending on the Comment on setting) matches.

·All: Filter will match if all comments of the feature or the feature's observations (depending on the Comment on setting) matches.

·None: Filter will match if no comment of the feature or the feature's observations (depending on the Comment on setting) matches.

Table 1: Settings for this view filter term type

Operator

Description

Equal

Tests for an exact but case insensitive match with the given comparison string.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Contains

Filters for all strings that contain the given comparison string.Comparison is done case insensitive.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Start with

Filters for all strings that start with the given comparison string. Comparison is done case insensitive.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Ends with

Filters for all strings that end with the given comparison string. Comparison is done case insensitive.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Pattern

Filters for all strings that contain the given comparison pattern. Comparison is done case insensitive.

Wildcard characters are supported in the comparison pattern.

Table 2: Comparison operators

Wildcards in comparison string

Wildcard character | Description | Example
% | Any string of zero or more characters. | %Name% matches AB Name as well as AB Name CD as well as Name1 %Name% does not math AB Nam CD %Name does not math Name CD
_ | Any single character. | Feature _ matches Feature 1 as well as feature A
[] | Any single character within the specified range ([a-f]) or set ([abcdef]). | Feature [12345] matches Feature 1, Feature 3 but not Feature 9
[^] | Any single character not within the specified range ([^a-f]) or set ([^abcdef]). | Feature [^A-M] matches Feature M to Feature Z but not Feature A to Feature M

Table 3: Wildcard characters that can be used with the pattern operator

Performance of string comparison

Under certain circumstance string comparison can be time consuming and for huge amounts of comments. Performance is of course always depending on your system environment the amount of data you have in your system and your overall system load.

When querying huge amounts of comments following hints might help to specify optimal filters:

·Using the like operator with a comparison string that includes wildcard characters needs a full scan of all comments and is therefore O(n) with n being the total number of stored comments for features or observations.

·The Contains and Ends with operators need to scan all comments and are therefore O(n) with n being the total number of stored comments for features or observations.

·The Equal and starts with operators use an indexed query and are therefore O(log n) with n being the total number of stored comments for features or observations.

The system stores the execution time of each view when it evaluates the view members, see view member caching for details.


Contradition

Navigation: Application Server > Structure > Views > View filter term types > Common >

Contradiction

Last edited: 10/5/2017 11:51:46 AM

This filter term matches no feature. This filter term is used by the Application Server as the default filter term in the filter expression of a new root view if the user did not supply another filter expression.


Creation or modification time stamp

Last edited: 10/5/2017 11:51:46 AM

This filter term type can be used to filter for creation or last update timestamp of features or observations and comments related to features. It returns all features where the created timestamp or last updated timestamp of specific feature data is in a given range.

Setting

Description

Filter on

Defines if creation timestamp or last update timestamp is used for filtering.

Filter for

Defines what data is used for filtering. Available options are

·Feature

·Observation

·Feature comments

·Observation comments

Time span type

The time span used for filtering can be either a dynamic time span or a static time span.

Note that when using dynamic time span the time span is calculated when the view filter statement is evaluated.

Also note the implication when using a creation or modification date filter in a view that is used a privilege object those. See also chapter view member caching.

Matching criteria

Since there can be more than one observation, feature comment and observation comments for a single feature the count criteria specifies how filtering is applied to these parts, see view filters introduction for details on the count criteria.

Table 1: Settings for the Creation or modification view filter


Tautology

Last edited: 10/5/2017 11:51:46 AM

In logic, a tautology is a formula which is true in every possible interpretation. And this is exactly what this filter term does it matches each and every feature. Note that as with every other filter term this also respects the setting for deleted features in views.


%Text%

Navigation: Application Server > Structure > Views > View filter term types >

Feature based

Last edited: 10/5/2017 11:51:16 AM

Feature based view filter terms filter features by inspecting characteristics of the features.


Axis

Last edited: 10/5/2017 11:51:46 AM

This filter term type will filter for all features that use an Axis Reference System based on the specified Axis. I.e. all features that use an axis reference system in its LSO-definition which is based on the specified axis will be matched by this filter term.

Setting | Description
Axis | Specifies the axis to filter for

Table 1: Settings for this view filter term type


Data domain

Navigation: Application Server > Structure > Views > View filter term types > Feature based >

Domain

Last edited: 10/5/2017 11:51:46 AM

The domain term can be used to filter for features that belong to a specific domain.

Setting | Description
Domain | Specifies the axis reference system the feature must use to match the filter term.
Exclude subordinate domains | If selected only features directly linked to the domain specified with the Domain setting will match the filter criteria. If not selected features linked to any subordinate domain will also match the filter criteria.

Table 1: Settings for this view filter term type

Including subordinate domains needs multiple database queries and - depending on the depth of your domain tree - might be significantly slower than querying one specific domain without subordinate domains (O(n) where n is the number of subordinate domains for the selected domain)


Data source

Last edited: 10/5/2017 11:51:46 AM

The Data source term type allows to filter for features with a specific data source.

Setting | Description
Data source | Specifies the data source a feature must have to match this filter term.

Table 1: Settings for this view filter term type


Feature type and subtype

Last edited: 10/5/2017 11:51:46 AM

The feature type view filter term type can be used to filter for features of a specific type and optionally of a specific subtype. Although subtypes are only defined for domains the term allows to select any feature subtype defined in any domain for the selected feature type.

Setting | Description
Feature type | Specifies the data source a feature must have to match this filter term.
Use feature subtype filter | This setting allows to specify if term should also filter for the feature subtype. If the term is set so that it does filter for subtypes and the subtype is not specified it filters for all features of the give type that are not assigned to a subtype, if the term is set to not filter for subtypes it will include all features of that type no matter if they have a subtype or not.
Feature subtype | The feature subtype to filter for (only used if Use feature subtype filter is set)

Table 1: Settings for this view filter term type


Features in group

Last edited: 10/30/2017 6:30:52 AM

This filter term type will match on features that are or are not contained in at least one group.

Setting | Description
Criteria | Specifies if the filter term matches either all features that are contained with at least one group or matches all feature that are not contained within any group.
Group feature type | If set, the filter will only match if the feature is in a group of that feature type.
Use subtype filter | If set the filter will only match if the feature is in a group of the given feature type and the given feature subtype.
Group feature subtype | If Use subtype filter is set this specifies the feature subtype to filter for. If null the term will filter group features that are not classified as any subtype.

Table 1: Settings for this view filter term type


Features in platform

Last edited: 10/30/2017 6:30:52 AM

This filter term type will match on features that are or are not contained in a platform.

Setting | Description
Criteria | Specifies if the filter term matches either all features that are contained with in a platform or matches all feature that are not contained within a platform.
Platform feature type | If set, the filter will only match if the feature is in a platform of that feature type.
Use subtype filter | If set the filter will only match if the feature is in a platform of the given feature type and the given feature subtype.
Platform feature subtype | If Use subtype filter is set this specifies the feature subtype to filter for. If null the term will filter platform features that are not classified as any subtype.

Table 1: Settings for this view filter term type


Geographic system

Last edited: 10/5/2017 11:51:46 AM

This filter term type will filter for all features that are located with the specified Geographic system.

Setting | Description
Geographic system | Specifies the geographic system the feature must use to match the filter term.

Table 1: Settings for this view filter term type


Instantiated features

Last edited: 10/5/2017 11:51:46 AM

This filter term type will match all features that were instantiated by the execution of a calculated feature. I.e. features that were created by an instantiating calculated feature.


Instantiating features

Last edited: 10/5/2017 11:51:46 AM

This filter term type will match all calculated features that are instantiating features with every execution.


Name or description

Last edited: 10/5/2017 11:51:46 AM

The Name or description term type can filter for feature name or description of features. The definition of the term includes the selection for name or description a comparison operator and a comparison string.

Setting | Description
Filter for | Specifies if the filter uses feature names or descriptions
Comparison operator | The comparison operator used, see Table 2 for details
Comparison string | The comparison string can be up to 4000 characters.

Table 1: Settings for this view filter term type

All comparisons are done case insensitive i.e. Feature1 is considered the same as feature1. If the term filters for feature name the comparison string must not be empty, when searching for description the comparison string can be empty to search for 'undescribed' features. The comparison string can have a maximum length of 200 characters when filtering for name and a maximum length of 4000 when filtering for description: Table 1 shows the supported string comparison operators, table 2 shows the wildcard characters allowed with the like comparison operator.

Operator

Description

Equal

Tests for an exact but case insensitive match with the given comparison string.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Contains

Filters for all strings that contain the given comparison string.Comparison is done case insensitive.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Start with

Filters for all strings that start with the given comparison string. Comparison is done case insensitive.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Ends with

Filters for all strings that end with the given comparison string. Comparison is done case insensitive.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Pattern

Filters for all strings that contain the given comparison pattern. Comparison is done case insensitive.

Wildcard characters are supported in the comparison pattern.

Table 2: Supported string comparison operators

Wildcard character | Description | Example
% | Any string of zero or more characters. | %Name% matches AB Name as well as AB Name CD as well as Name1 %Name% does not math AB Nam CD %Name does not math Name CD
_ | Any single character. | Feature _ matches Feature 1 as well as feature A
[] | Any single character within the specified range ([a-f]) or set ([abcdef]). | Feature [12345] matches Feature 1, Feature 3 but not Feature 9
[^] | Any single character not within the specified range ([^a-f]) or set ([^abcdef]). | Feature [^A-M] matches Feature M to Feature Z but not Feature A to Feature M

Table 3: Wildcard characters that can be used with the like operator

Under certain circumstance string comparison can be time consuming and for huge amounts of data. Performance is of course always depending on your system environment the amount of data you have in your system and your overall system load.

When querying huge amounts of features following hints might help to specify optimal filters:

·Using the like operator with a comparison string that includes wildcard characters needs a full scan of all features and is therefore O(n) being the total number of stored features.

·The Contains and Ends with operators need to scan all features and are therefore O(n) with n being the total number of stored features.

·If you search for feature name the Equal and starts with operators use an indexed query and are therefore O(log n) with n being the total number of stored features.

The system stores the execution time of each view when it evaluates the view members, see view member caching for details.


Projected system

Last edited: 10/5/2017 11:51:46 AM

This filter term type will filter for all features that are using a specific projected system to express their spatial location.

Setting | Description
Projected system | Specifies the projected system the feature must use to match the filter term.

Table 1: Settings for this view filter term type


Region

Last edited: 10/5/2017 11:51:46 AM

This filter term filters for features based on their spatial data. The term uses a feature of type Region to define the spatial boundary and will return all features that are located within that spatial boundary.

This filter can search for features regardless of the spatial reference system. It will automatically transform the Region in order to get accurate results.

This filter will never include the region feature that is used to specify the region of interest.

Setting

Description

Region

Specifies the feature that defines the spatial boundary. This feature is never included in the Members of the view

Spatial Operator

Intersect: Two geometries are said to intersect if they share at least one point in common. That common point (or

points) may lie either on the boundary or the interior of the geometries concerned.

Within: Geometry A is said to be within geometry B if the interior of A is completely contained within B. Specifically, the two geometries must meet the following criteria:

·The interiors of both geometries must intersect.

·No point from geometry A may lie in the exterior of geometry B (although points from geometry A may lie in the boundary of B).

Contains: Geometry A contains geometry B if the following criteria are met:

·The interior of both geometries intersects.

·None of the points of geometry B lies in the exterior of geometry A.

Include features using projected coordinate systems

If set the view filter will search for features using a geographic coordinate system.

Default: true

Include features using geographic coordinate systems

If set the view filter will search for features using a geographic coordinate system.

Default: false

Include features using axis reference systems

If set the view filter will search for features using a geographic coordinate system.

Default: false

Table 1: Settings for this filter term type


Specific features

Last edited: 10/5/2017 11:51:46 AM

This term type filters for specific features. It allows the definition of a list of features the filter shall include, therefore this filter term is not dynamic as most other filter terms but will always return the same set of features irrespective of the data stored with these features.

Setting | Description
Feature Ids | Specifies the IDs of the features that match the filter. The filter term allows you to define a maximum number of 128 features.

Table 1: Settings for this view filter term type


%Text%

Navigation: Application Server > Structure > Views > View filter term types >

Observation based

Last edited: 10/5/2017 11:51:30 AM

Observation based view filter terms filter features by inspecting characteristics of the features' observations.


Alarm

Last edited: 10/5/2017 11:51:46 AM

This filter term type can be used to filter features with alarms.

Setting | Description
Acknowledgment status | Filter term will only match features with alarms being in the specified acknowledgment state.
Severity | If set the filter term will only match features with alarms that have a severity greater or equal to the specified value.
Time span type | Specifies which type of time span is used (if any) to filter alarms by issue date.
Time span definition | This is a set of settings defining the issue date filter. Available settings depend on the setting Time span type.
Title contains | If set to a non empty string the filter term will only match features having alarms with a title that contains the specified string. Containment is checked case insensitive.

Table 1: Settings for this view filter term type


Observation count

Last edited: 10/5/2017 11:51:46 AM

The observation count term type allows to filter for features depending on the number of observations they have.

Setting | Description
Compraison operator | Specifies the comparison operator that is used in the filter ·equal ·not equal ·greater than ·greater or equal than ·lower than ·lower or equal than
Comparison value | The number to which the observation count is compared

Table 1: Settings for this view filter term type


Observation property value (classification)

Last edited: 10/5/2017 11:51:46 AM

This term type allows to filter for the value of a specific classification property in the property structure instance stored for observations. Since the property structure for the observation is defined by the feature type a term of this type implies the filtering for a specific feature type.

Setting | Description
Observation matching criteria | Defines the criteria that defines how many observations have to fulfill the filters comparison.
Feature type | Defines the feature type
Property matching criteria | Defines the matching criteria for properties within a property structure instance. This is only respected with hierarchical property structures.
Property | The numeric property used with the filter term
Comparison value | The classification element that has to be matched

Table 1: Settings for this view filter term type


Observation property value (numeric)

Last edited: 10/5/2017 11:51:46 AM

This term type allows to filter for the value of a specific numeric property in the property structure instance stored for observations. Since the property structure for the observation is defined by the feature type a term of this type implies the filtering for a specific feature type.

Setting | Description
Observation matching criteria | Defines the criteria that defines how many observations have to fulfill the filters comparison.
Feature type | Defines the feature type
Property matching criteria | Defines the matching criteria for properties within a property structure instance. This is only respected with hierarchical property structures.
Property | The numeric property used with the filter term
Comparison operator | The used comparison operator
Comparison value | The numeric comparison value.

Table 1: Settings for this view filter term type


Observation property value (quantity)

Last edited: 10/5/2017 11:51:46 AM

This term type allows to filter for the value of a specific quantity property in the property structure instance stored for observations. Since the property structure for the observation is defined by the feature type a term of this type implies the filtering for a specific feature type.

Setting | Description
Observation matching criteria | Defines the criteria that defines how many observations have to fulfill the filters comparison.
Feature type | Defines the feature type
Property matching criteria | Defines the matching criteria for properties within a property structure instance. This is only respected with hierarchical property structures.
Property | The numeric property used with the filter term
Comparison operator | The used comparison operator
Comparison unit | Specifies the unit of the comparison value. The filter respects units of quantities, i.e. it will compare values after converting them to the same quantity.
Comparison value | The numeric comparison value.

Table 1: Settings for this view filter term type


Observation time-span

Last edited: 10/5/2017 11:51:46 AM

Observation time span term allows user to filter feature based on a timestamp stored with the observations of the feature. The system stores two timestamps for each observation that can be filtered with this term.

Setting | Description
Filter on | Defines if the observation sampling timestamp or the observation result timestamp is used by this filter term.
Matching criteria | ·Any: Filter will match if any of a feature's observation is in the specified time-span. ·All: Filter will match if all of a feature's observation is in the specified time-span. ·None: Filter will match if none of a feature's observation is in the specified time-span.
Time span type | The time span used for filtering can be either a dynamic time span or a static time span. Note that when using dynamic time span the time span is calculated when the view filter statement is evaluated.
Time span definition | This is a set of settings defining the issue date filter. Available settings depend on the setting Time span type.

Table 1: Settings for this view filter term type


Feature relations

Last edited: 10/5/2017 11:51:18 AM

The Application Server provides several different possibilities to establish relations between features. Different types of features relations are used to express different logical relations between features.

Feature relations are always directed, i.e. there is always a source feature and a destination feature that are linked by the relation.

Some types of relations are used by Redbex for analyzing, processing and presenting data.

If a user has the permission to read a feature he implicitly has the permission to list all features that are related to this feature (incoming and outgoing relations).


Calculation relations

Last edited: 10/5/2017 11:51:16 AM

Features (including calculated features) can be part of the calculation algorithm of a calculated feature. The Application Server will allow to trace following calculation relations between features:

·Determination of calculated features in which a specified feature is used.

·Determination of features used in the calculation algorithm of a specified calculated feature.


%Text%

Navigation: Application Server > Structure > Feature relations >

Feature associations

Last edited: 10/5/2017 11:51:16 AM

Feature associations are directed links from a single feature or observation to other features. Feature associations are part of associated data.


Feature link relations

Last edited: 10/5/2017 11:51:16 AM

A feature can link to other features via a feature link property in the type specific data of the feature or of an observation of a feature. The feature link property defines via validation rules which feature types can be linked from this specific property. The feature or observation that stores the reference to another feature is the the source of this feature link relation, the linked feature is the destination of the feature link relation.

The system can determine all features that are linked to a specific feature through a feature link relation, i.e. all features that are destination in a feature link relations stored for a specific feature. The system can also determine all features that link to a specific feature, i.e. all feature that are source in a feature link relation to the specific feature.


Group relations

Last edited: 12/21/2017 10:47:08 AM

Features of class group can contain other features. A feature can be contained in any number of group features and each group feature can contain any number of features. The features assigned to a group feature are called members of that group feature. Groups features are a good way to structure contents but are also used in data processing and data presentation.

The feature type of the group feature defines what feature types are allowed as member features. The Application Server can list all members of a group feature. For each feature all group features it is a member of can be determined.

To add a feature as member to a group feature or to remove a feature from a group feature the user must have Modify (1) on the group feature and Read (0) on the member feature.


Instantiation relation

Last edited: 10/5/2017 11:51:16 AM

If a feature is created as result of the execution of an instantiating calculated feature that feature will remember the feature it was instantiated from.

The Application Server can therefore list all features instantiated from a specific calculated feature and it can determine the calculated feature from which an instantiated feature was instantiated.


Platform relations

Last edited: 12/21/2017 10:50:28 AM

Features of class platform feature can contain other features. The assignment of a feature to a platform feature is exclusive. I.e. if a feature can only belong to one platform feature, it cannot belong to another platform feature at the same time. Features linked to a platform are called members of that platform. Platform relations may be hierarchical. I.e. a platform feature might have member that is a platform feature itself.

The feature type of the platform feature defines which feature types can be member of the platform. The Application Server can list all members belonging to a platform feature. If a feature is member of a platform feature the system can determine the platform feature.

To add a feature as member to a platform feature the user must have Modify (1) on the platform feature and Modify (1) on the member feature.

To remove a feature from a platform feature the user must have Modify (1) on the member feature.


%Text%

Navigation: Application Server > Structure >

Workspaces

Last edited: 10/5/2017 11:51:46 AM

Views can be exposed as workspaces. Workspaces encapsulate a view together with additional settings and are used to expose specific views to specific clients. This way the complexity of the view tree can be hidden from clients (like mobile applications etc) and the data available to specific clients can be centrally managed.

A workspace consists of:

·Workspace name and description: Two strings that help users to understand the contents of the workspace.

·Workspace type: Every workspace is of a specific workspace type. The workspace type defines which type-specific settings are available for that workspace and might also implement specific feature filters that are implicitly added to the underlying view.

·Underlying view: The underlying view specifies the features that will be available in this workspace. Note that depending on the workspace type the features might be additionally filtered based on the workspace type's internal logic.

·Type specific settings: Every workspace type can have its own specific settings that allow the user to specify the behavior of the workspace.

·User / user group association: Workspaces can be associated to users and user groups. Only those users associated with a specific workspace will see this workspace. Note that a workspace does not have its own privileges. However when adding a user or user group to a workspace the Application Server will give those users and user groups the view permissions List features (2), Read features (100), and the view permission Read observations (103)

One view can be exposed as many workspaces.


GeoMapApp workspace type

Last edited: 12/27/2017 9:10:30 AM

This workspace type is mainly used to expose data to Redbex <%GEOMAPAPP%>.

Workspace type specific settings

This workspace type has no type specific settings.

Additional filters

This workspace type has no additional filters.


Feature Sets

Last edited: 10/5/2017 11:51:16 AM

Feature sets are sets of features a user can create in order to have fast access to repeatedly used features. Feature sets are stored on a per user basis, i.e. one user cannot see or modify the feature sets created by another user.

Features in a feature set are called feature set members. One feature can be member of any number of feature sets. A feature set is limited to a maximum of 128 features.

Deleting a feature set, or removing features from a feature set does not delete the set members.


Grouping path

Last edited: 10/5/2017 11:51:22 AM

To give the user the possibility to organize sets of objects (e.g. axes, feature types, etc.) in a hierarchical (i.e. tree-like) structure Redbex supports specification of a grouping path for many different types of objects. Clients (like the Smart Client) can use this information to show objects in a tree-like structure. This way the grouping path can help you to organize large sets of objects in a very flexible way.

A grouping path is a string defining the path to the object. The path consists of nodes and the \ (backslash) as node delimiting character. The grouping path Daily Evaluation\Geotechnics\Inclinometer for example consists of 3 nodes Daily Evaluation, Geotechnics and Inclinomater.

Grouping paths in Redbex support multilingual data, i.e. you can define different grouping paths for different languages.

Example: For the chart templates defined as shown in table 1 the grouping paths would result in a structure as shown in figure 1

Template name | Grouping path
Template 1 | General
Template 2 | General
Template 3 | Daily Evaluation\Geotechnics
Template 4 | Daily Evaluation\Geotechnics
Template 5 | Daily Evaluation\Geology
Template 6 |
Template 7 | Daily Evaluation\Geotechnics\Inclinometer

Table 1: The grouping paths for chart templates in this example

Figure 1: The resulting structure using the defined grouping paths


Processing

Last edited: 10/5/2017 11:51:32 AM

In order to get more information out of the stored content the Application Server provides data processing possibilities that allow the user to transform stored content. Table 1 summarizes the pros and con.

 | Calculated properties | In-Feature Calculation | Calculated features
Real time calculation: Processing is executed on every modification or save. |  |  |
Support on clients possible: Processing results can be shown on the user interface of a client immediately. |  |  |
Deployment with modular updates: Formulas are part of the feature type and therefore deployed with modular updates |  |  |
Result stored in same feature: Result of a processing is modifying the original feature. |  |  |
Formulas based on observation data: Formulas can be based on any data in a single observation |  |  |
Formulas based on feature data and observation data of same feature |  |  |
Processing is performed as a job |  |  |
Deployment with new version of Redbex Application Server |  |  |
Can operate on multiple observations of the same feature |  |  |
Can operate on multiple features, |  |  |
User-defined algorithm: The processing algorithm can be changed by the user. |  |  |

Table 1: Overview of processing possibilities in Redbex


%Text%

Navigation: Application Server > Processing >

Calculated features

Last edited: 11/9/2017 8:05:48 AM

Calculated features are features whose observations are created by the execution of a defined calculation algorithm. A calculation algorithm is based on features (or other calculated features), their observations and user defined calculation settings. Optionally a calculated feature can also copy parts of its feature data from another feature.

Calculated features behave mostly like regular features (= non calculated features) with following differences:

·The observation data of calculated features cannot be modified, no new observations can be added and no observations can be deleted. However it is possible to convert a calculated to a regular feature.

·Calculated features do not validate observation data.

As regular features, calculated features are always of a specific feature type that is defined when the calculated feature is created. Calculated features can be of any feature type class. Calculated feature of class group, absolute platform, relative platform and network can have member features but again only the observations of the calculated feature itself will be calculated.

The execution of a calculated feature i.e. the generation of observations for that calculated feature and the optional copying of feature data, is not triggered when the data is queried from the Application Server but at specific points in time or on request of a user. Therefore the data in a calculated feature might not reflect the latest changes in the data of the source features used in the calculation algorithm.

Defining a calculated feature builds up a relation between source features used in the calculated feature's algorithm and the calculated feature itself. These relations are updated whenever the algorithm is modified.


Permissions on calculated features

Last edited: 10/5/2017 11:51:30 AM

As with regular features permissions on calculated features are assigned either via views or directly on the calculated features itself. Table 1 gives an overview of feature permissions and describes specifics for calculated features

Permission | Specifics for calculated feature
Read | The read permission also allows to execute a calculated feature.
Modify | Includes the permission to edit the calculation algorithm, and other calculation settings
Comment | none
Read observations | none
Modify observations | Observations of calculated feature can never be modified even if this permission is given.
Comment observations | none
Observation monitoring | none
Modify configuration data | none
Manage approval workflows | none

Table 1: Specifics for feature permissions on calculated features.


Instantiating calculated features

Last edited: 10/5/2017 11:51:26 AM

Whenever a calculated feature is executed the observations of this calculated feature are modified. With instantiating calculated features this is different. Instantiating calculated features will create new features every time they are executed and will store the results of the calculation algorithm as observations of that newly created features. Instantiating calculated features are useful for creating snapshots of data at specific points in time.

The features generated are regular features of the same feature type as the calculated feature. The newly create features will be named according to following scheme:

<Instantiating calculated feature name> <YYYY-MM-DD HH:MM:SS +TimeOffset>

Domain and subtype of the newly created features are the same as in the calculated feature.

For each feature created from an instantiating calculated feature the application server creates a calculation relation.

Instantiating calculated features will only execute if the user who last edited the calculation algorithm has the permission to create features in the domain of the calculated feature.

If incremental execution is turned on for the calculation algorithm the newly created features will only include the results of the algorithm applied to the observations of source features that were added since the last execution.

Depending on the view structure it is possible that the newly created instance is not visible or not accessible, make sure that you have an appropriate view that will include the newly created features.


Converting calculated feature

Last edited: 10/5/2017 11:51:12 AM

A calculated feature can be converted into a regular feature. This is useful if you want to edit the data of a calculated feature. A calculated feature can only be converted if it is not currently calculated.

Converting a calculated feature to a regular feature will delete the calculation algorithm and all calculation settings as well as the execution history of the calculated feature and all calculation relations that exist for this converted feature.

A calculated feature cannot be converted if it is currently being executed.

Any stored job definitions of type calculated feature execution that reference the feature to be converted will be deleted. Also any queued jobs of type calculated feature execution that reference the feature to be converted will be removed fro the database. Note that active jobs on the queue will not be deleted and will fail when they are executed.

There is no possibility to convert a regular feature into a calculated feature. Since the observations type specific data is not validated for calculated features you might end up with a regular feature with invalid data.


Calculation algorithm

Last edited: 10/5/2017 11:51:06 AM

In order to be calculated a calculated feature needs a calculation algorithm that defines how the observations of the calculated feature are generated. The calculation algorithm consists of atomic calculations. Each calculation is the instance of a calculation type . The System defines the available calculation types and allows the user to freely combine instances of these types to form a calculation algorithm.

Each calculation may require input data and produces a series of observations as output. The property structure used for the type specific observation data in the output is always conforming to a specific feature type. The input of a calculation can be either the observations of features (which are then called source features) or the output of another calculations. This way calculations can be chained together to form a calculation algorithm. Each calculation algorithm has exactly one final calculation, the output of this calculation will be persisted as observations of the calculated feature or as the observations of the instantiated feature in case of instantiating calculated features. The feature type the final calculation output conforms to, must always match the feature type of the calculated feature, since the output of this last calculation step will be persisted as observations of a feature.

Figure 1 shows an example of a calculation algorithm consisting of seven calculations. As depicted in the example one calculation can take data input from features or other calculation steps. Any number of calculations and features can be combined in one calculation algorithm. Note that a calculation algorithm can also use calculated features as source features. Calculation 7 is the final calculation, the output of this calculation will be persisted as observations of the calculated feature or as the observations of the instantiated feature in case of instantiating calculated features.

For some calculations it is necessary to know about the domain of the features or calculations that are connected to its input pins. E.g. a merge calculation can only be executed if all connected source features or connections use the same classifications for all properties of type classification - and the used classification depends on the domain the feature is in. The output of a domain is not natively belonging to a domain but it inherits its domain from the first connected feature or calculation. Since at the beginning of each calculation algorithm data is always read from either features or other calculated features this approach guarantees that the output of each calculation is belonging to a domain.

Figure 1: Example of a calculation algorithm


Validation

Last edited: 10/5/2017 11:51:06 AM

The Application Server tests the validity of a calculation algorithm defined for a calculated feature before the calculated feature is executed. If the calculation algorithm for a calculated feature is invalid the execution is canceled or in case of manual execution is not even started. The Application Server will not test validity of a calculation algorithm when it is created or modified, it is therefore possible to store invalid calculation algorithms. The Application Server provides the possibility to test the validity of a calculation algorithm at any time.

Following rules must be matched for a calculation algorithm to be valid.

·There is at least one calculation in the algorithm

·There is exactly one final calculation (output of this calculation is not used as an input for another calculation)

·The structure of the type specific data of observations generated by the final calculation conforms to the feature type of the calculated feature.

·There is at least one calculation hat has either no input pin or whose input pins are all connected to features.

·The calculation algorithm has no loops where the output of one calculation is the input of a predecessor of this calculation.

·Each calculation in the algorithm is valid by

·None of the source features referenced in the algorithm are deleted

·All input pins are connected to features or other calculated features

·Input pins of type feature only are not connected to calculated features


Execution sequence

Last edited: 10/5/2017 11:51:14 AM

The execution sequence of calculations with in a calculation algorithm is automatically determined by the Application Server. I.e. the user does not have to care about the execution sequence for the calculations within an calculation algorithm he just defines the connections between calculations and feature.

Calculations within an calculation algorithm are executed in following sequence: First all calculations that have no input pins, or have input pins that are only connected to features are executed. Execution of all these calculations is done in parallel. After that, whenever one calculation has finished the System checks for calculations that have input pins connected to features and already executed calculations. All the calculations found are then again executed in parallel.


Execution

Last edited: 10/5/2017 11:51:14 AM

The execution of a calculated feature includes the generation of observation results for the calculated feature, copying of feature data from a source feature to the calculated feature (optionally), and creating new features (in case of auto versioning calculated features). Figure 1 shows an (abstracted) activity diagram of the execution of a calculated feature.

The execution of calculated features is triggered at specific points in time or by manual advice of a user and is not done on the fly i.e. when the data of the calculated feature is accessed. Therefore the data of a calculated feature will not necessarily represent the latest changes done to the source features. The execution of calculated features is always performed as a job. In order to provide reliable calculation results the execution of calculated features uses feature locking on the source features.

A calculation algorithm of a calculated feature will only use those observations of its source features that were created before the execution was started.

Calculated features marked as deleted are never executed.

The execution of a calculated feature is always performed a s a job, i.e. the execution runs asynchronously as a background process on the Application Server.

The user can either trigger the calculation of a specific calculated feature from the client or create a stored job definition that will recalculate a number of calculated features. A third way of triggering the execution of a calculated feature is using a trigger recalculation action in an observation monitoring definition.

Figure 1: Activity diagram showing the workflow (simplified) of the execution of a calculated feature


Execution history

Last edited: 10/5/2017 11:51:14 AM

The system will record an execution history for each calculated feature. This history includes information about when the execution was actually started and when it was ended and the overall success status of the execution. Table 1 lists the possible success status.

The execution history will also link to the queued job that actually executed the calculated feature. Details about the execution (e.g. failure reasons) can then be found in the job execution log.

When the execution of a calculated feature is started a execution history entry is created, at that point in time the success status is set to unknown. When the execution finishes this entry is updated with the success status and the end date.

Fore each feature the calculation history can be read by any user having Read permissions on the feature. The execution history for a calculated feature cannot be deleted and is kept for the lifetime of the feature.

Success status |
Success | The execution was successful.
Failed | The execution failed due to some reason, in this case the job log may carry more detailed information
Unknown | The execution is either still pending or finished with an unknown status.

Table 1: Possible success status of an execution of a calculated feature


Preventing double execution

Last edited: 10/5/2017 11:51:32 AM

The Application Server will ensure that one calculated feature is only calculated once at the same time. A second execution of the same calculated feature at the same time will fail.


Triggering calculation execution

Last edited: 10/5/2017 11:51:44 AM

The Application Server provides several different possibilities to define when the execution of a calculated feature shall be triggered. No matter how the execution of a calculated feature is triggered the execution itself is always performed as a job on the Application Server. The actual start time for a execution of a calculated feature is therefore also depending on the job system.

Execution on users request

For each calculated feature a user can trigger an execution manually. When the calculated feature is currently calculated manually triggering execution will not work. Triggering the execution of a calculated feature requires the permission Modify observations (4) on that calculated feature.

Execution on custom schedule

To automatically (and repeatedly) execute calculated features the Application Server provides the job type Calculated feature execution. This job type allows you to trigger the execution of a single calculated feature or of all calculated features that are member of a specified view or of all calculated features that are member of the specified domain.

Execution triggered from observation monitoring

A calculated feature can also be executed by an observation monitoring action.


Suppressing execution

Last edited: 10/5/2017 11:51:42 AM

The Application Server provides a possibility to globally suppress the execution of calculated features by using the global setting Processing: Disable execution of calculated features. Suppressing the execution of all calculations is meant for situations where the execution of jobs puts heavy load on the system and you want to quickly free more system resources or investigate the cause of the heavy load.

If the value of this global setting is set to true no calculated feature will be executed. The jobs that are used to execute the calculated feature will still run but terminate immediately, without performing any actual calculation. Already started executions will not be aborted.


Impersonation

Last edited: 10/5/2017 11:51:06 AM

Since calculated features are not executed on the fly i.e. as data is accessed, but as job, they are also not executed in the permission context of the accessing user. When calculated features are executed the Application Server executes them as that user who created or last modified the calculation algorithm i.e. the server impersonates the user who last edited the calculation algorithm when the calculated feature is executed. This has following implications:

·If the user who last edited the calculation algorithm does not have read permissions on one of the source features used in the calculation algorithm the execution of the calculated feature will not be successful.

·A user who does not have read permissions on any source feature of a calculation algorithm might still read the results of the execution of the calculated feature (if defined so by the feature privileges).


Copying feature data

Last edited: 10/5/2017 11:51:12 AM

Type specific data and spatial data stored stored with a calculated feature (as opposed to the observation data that is calculated by the defined calculation algorithm) can either be manually defined or copied form a specific source feature when the calculated feature is executed. Even if a calculated feature is configured so that the feature's data is copied from a source data, the calculated feature's data is still modifiable. Copying of the data is done on every execution of the calculated feature, manual changes to the calculated feature's data will be overwritten.

The two settings copy type specific data on execution and copy spatial data on execution can be specified for every calculated feature and define what feature data will be copied on execution of the calculated feature.

If copy type specific data is selected the property structure instance of the source feature will be copied and stored with the calculated features. The created copy will not include any binary data of the source feature.


Algorithm expansion

Last edited: 10/5/2017 11:51:02 AM

The algorithm used to generate the observations of a calculated feature might be based on other calculated features and these calculated features might again depend on other calculated features and so on. This provides a high level of flexibility when designing your calculation algorithms. The main question with calculated features that depend on other calculated features however is, if the algorithm should use the observations stored with the calculated features it depends on or if these observations should be recalculated. Both ways of handling these dependencies have their pros and cons. While using the (already calculated) observations of the calculated features needs less processing power and will therefore usually be faster (especially when dealing with huge amounts of data), the recalculation of observations provides results that are more up to date.

The Application Server leaves it up to the user how dependencies on other calculated features are handled by providing by providing the algorithm expansion functionality.Algorithm expansion expands the algorithm of a calculated feature with the algorithm of calculated features that are used as source features. In other words the algorithms of multiple calculated features are merged dynamically. Figure 1 shows an example of how algorithm expansion works. Note that algorithm expansion builds up a new algorithm but does not actually recalculate the calculated features it depends on.

To further improve performance and prevent unnecessary executions the algorithm expansion can be configured with the Algorithm expansion If older than setting. The value of this setting defines that if the last successful execution of a calculated feature that is used as a source feature in an other calculated feature is longer ago than the this time span the algorithm will be expanded. If the value for algorithm expansion if older than is set to zero the algorithm will always be expanded

Note that while each calculated feature has its own algorithm expansion if older than setting the setting for the topmost calculated feature will be used for all calculated source features (hierarchically) if the algorithm of that feature is executed.

Figure 1: Example of an Algorithm expansion.


Locking of source features

Last edited: 10/5/2017 11:51:28 AM

After the calculation algorithm has been expanded and before the algorithm is executed the source features (regular features and calculated features) are locked.

The type of lock(s) applied to the source features depends on the actual calculation types used. All source features will be locked against observation modification and observation deletion. If the calculation type also uses the data of the feature itself it will also apply a lock for modifying the feature data. Since all locks applied to source features are shared locks any number of calculations can use the same source features at the same time. If locking on any source feature fails the execution of the calculated feature will fail.

If a calculation algorithm is based on another calculated feature and if that calculated feature is expanded that calculated feature will not be locked. Although locks are applied to all source features of the algorithm at the beginning of the algorithm execution, locks are removed as soon as the feature is not needed any more in the execution of the algorithm.


Waiting for calculated features

Last edited: 10/5/2017 11:51:46 AM

If the algorithm is based on calculated features and if the calculated features it is based on are not expanded it might occur that when executing that calculated feature the calculated source feature is currently also calculated. Each calculated feature can be configured to wait and retry execution later in such cases. Two settings can be used to define how the system shall handle such situations.

Setting | Effect
Wait time between tries | If a source calculated feature is currently being calculated the Application Server waits that long before it will try again.
Maximum tries | The Application Server will try that many times before it gives up and the execution will fail. Minimum value for this setting is 0 which would cause the execution to fail immediately if one of its source calculated features is being calculated.

The maximum total delay that might be introduced by waiting for another calculated feature to complete its execution is therefore Wait time between tries * (Maximum tries -1)


Detection of observation changes

Last edited: 10/5/2017 11:51:14 AM

The generation of observation results for the calculated feature is usually the most resource demanding process during the execution of calculated features. Therefore the Application Server tries to detect if changes (modify, add, delete) were made to observations of the source features since the last execution of the algorithm. If no changes are detected there is no need to execute the algorithm. In that case the success status in the execution history will still be success.

Instantiating calculated features will skip the detection of observation changes and will always execute the algorithm. I.e. even though no data was changed a new feature instance will be created and observations will be generated.


Calculation parallelization

Last edited: 10/5/2017 11:51:06 AM

In order to minimize the overall execution time, the execution of a calculation algorithm can start the more than one calculation in parallel. How many and which calculations of a calculation algorithm are effectively executed in parallel is determined by the system and cannot be influenced by the user.


Execution performance

Last edited: 10/5/2017 11:51:14 AM

When huge amounts of data are processed by the execution of a calculated feature, the application server will store intermediate calculation results to files on the Application Server's file system. These files are for internal use of the Application Server and do not need to be backed up. The directory where these temporary files are stored is configured in the configuration file.

The global setting Processing: Disk writing threshold setting defines how many observations will be handled in memory by each calculation before it begins to write temporary results to disk. Note that due to the fact that numerous calculated features can be executed in parallel and within each executed algorithm numerous calculations can be executed in parallel the total number of observations held in memory for processing can be much larger that this number. Also depending on the complexity of the observations type specific data the memory consumption can differ. Nevertheless, with some experience and sure instinct this setting can be used to tune memory consumption.


Incremental execution

Last edited: 10/5/2017 11:51:24 AM

Using incremental execution can radically reduce the time and resources needed for the execution of a calculated feature. Without incremental execution the Application Server will delete all existing observations of the calculated feature first and then (re)generate observations from all the source features used in the calculation algorithm. For huge amounts of observations this process is obviously very time and resource consuming.

Incremental execution does not delete existing observations and generates new observations only from observations that were added to the source features after the last execution of the calculated feature. In many cases this approach will need a lot less time and resources to complete. Incremental calculation can only be performed if the calculated feature and the source features of this calculated feature fulfill following criteria.

·All calculation types used in the expanded algorithm support incremental calculation.

·If the calculated feature has been executed before, no observations with a sampling timestamp less than the highest sampling timestamp detected on last execution of the calculated feature are present

·If the calculated feature has been executed before, no observations with a creation timestamp before the last execution of the calculated feature were modified after the last execution of the calculated feature

·Last observation purge is not after last execution

Some calculation types need to always operate on all observations of the source feature (or calculation), e.g. calculating the median of a numerical property within the property structure of observations will need to read all values of this property. Other calculation types (like the Copy calculation type) can easily operate only on the newly added observations.

Refer to the documentation of calculation types to see if a specific calculation type supports incremental calculation.

The user can set the incremental execution option of each calculated feature to one of the value described in table 1. By default each calculated feature will be set to Incremental if supported by algorithm and no modifications detected.

Incremental execution

Description

Incremental if supported by algorithm and no modifications detected

The calculation will be performed incremental if supported by the algorithm and if no changes (modification, delete) were made to the observations of source features that were handled in previous executions.

Incremental if supported by algorithm

The calculation will be performed incremental if supported by the algorithm. If changes were made to observations of source features handled in previous executions the calculation will still be performed incremental. This option will only generate consistent results if no observations of the source features used in the expanded algorithm were modified or deleted since the last execution of the calculated feature. This is usually the case if the feature records sensor data from some automated sensor.

When your calculated feature is based on features with a huge number of observations and if those features are usually not modified this option is optimal.

Use this option only if you really do not want to respect those modifications!

Non-Incremental

The calculation will not be performed incremental even though the algorithm would support it. This option can be useful if you previously used the Incremental if supported by algorithm option.

Also when the calculated feature operates on a small number of observations the this option might be faster.

Table 1: Possible settings for the incremental option


Calculation types

Last edited: 10/5/2017 11:51:06 AM

The calculations used in calculation algorithms are instances of calculation types provided by the Application Server. Each calculation type defines the actual calculation that is done when an instance of this calculation type is executed, the needed input data, the output data it produces, and additional configuration options the user can or has to define for the calculation.


Input

Last edited: 10/5/2017 11:51:06 AM

The input to calculations i.e. the data that the calculation will process can be provided either by features or by the output of other calculations in the same calculation algorithm. When an calculation algorithm is defined features or calculations are connected to the input pins of a calculation. The available input pins for a calculation are predefined by the calculation type.

There are two types of input pins. The type of the input pin defines if features or features and the output of other calculations can be connected to the input pin. Feature only input pins can not get their input from other calculations. Feature or calculation input pins can either be connected directly to features or to the output of another calculations.Feature only input pins cannot be connected to other calculated features.

Input pin constraints further define which features or calculations can be connected to an input pin of a calculation. This constraint is defined by the calculation type and therefore not modifiable. Table 1 lists the constraints that can be applied to input pins.

Depending on the constraint that is applied to an input pin the pin can allow multiple connections. I.e. more than one feature and/or calculations can be connected to that input pin. An input pin with a constraint that allows multiplicity will define a minimum and a maximum number of features and/or calculations that can be connected to that input pin. When multiplicity is allowed the sequence of connected features or calculations might be important for the calculation.

Constraint | Notes | Multiplicity possible
None | A feature of any type or a calculations with an output conforming to any type can be connected to that input pin | No
Feature type | Only features of a specific feature type (predefined by the calculation type) or calculations that generate observations conforming to features of that specific feature type can be connected to the input pin. | Yes
Same feature types | Any feature type can be connected to that input pin, all connected features have to be of the same feature type. The feature type is not predefined by the calculation but defined by the first feature or calculation connected to that pin. | Yes
Rules | Custom rule that defines characteristics the feature's or calculations observations and its property structure must have (see Table 2) | No

Table1: Constraint types for input pins

If an input pin is constrained with the constraint type rules it will include one or more rules that define which characteristic the observations must have.

Rule

Description

Observation location type rule

Only features that have observation location or calculations that conform to..

No

Observation property structure rules

Only features whose observation property structure conforms to the defined rules can be used at that input pin.

Observation property structure rules, define which property types are needed at which level of the property structure. E.g. the rules defined for an input pin might require that the features or calculations connected to that input pin one have a numerical property on level one. When a feature or calculation output is connected to that pin the user will then have to specify which numerical property of level one shall be used by the calculation.

No

Table 2: Rules


Output

Last edited: 10/5/2017 11:51:06 AM

The output of a calculation i.e. the result of the execution of a calculation is a series of observations with a property structure for type specific observation data that conforms to the property structure defined for the observations of a specific feature type. The property structure for type specific observation data of the output of a calculation is simply called the output format, and named after the feature type that defines the same format for observations of features of that type. E.g. If the output format of a calculation is Hydrostatic pressure it means that the property structure used for type specific observation data of the output of this calculation is the same property structure as defined for observations of a feature type called Hydrostatic pressure.

Table 1 lists the three different ways a calculation can define its output format.

Name | Notes
Explicit | Calculation types with explicit output format predefine the output format and will always produce observations of this output format.
Implicit by pin | The output format of observations generated by calculations with implicit by pin output definition is defined by the feature or calculation connected to a specially designated input pint, hat pin is called the defining input pin. Therefore the output format of calculations of this type is not fixed but depends on the algorithm.
Implicit by setting | The output format of observations generated by calculations with implicit by setting output definition, will have a configuration setting that allows the user to choose the output format from a list of feature types.

Table 1: Different ways how the property structure for type specific observation data of a calculation output can be defined.


Validation

Last edited: 10/5/2017 11:51:06 AM

Before a calculation algorithm is executed it is validated and part of this validation is that all of the calculations within that algorithm will validate themselves. Only if all calculations are valid the algorithm will execute. Note that the Application Server allows to store invalid calculation algorithms, and calculation algorithms can also get invalid as other data in the systems changes.

All calculations, regardless of their type will use following validation rules:

·All input pins are connected to either features or other calculations.

·All constraints on input pins are met (including type, multiplicity etc.)

·Input pins with multiplicity conform to the multiplicity boundaries.

·Configuration settings are valid (depending on the specific calculation type)

Specific calculation types might add additional validation rules, see the calculation type documentation for more details.


Configuration

Last edited: 10/5/2017 11:51:06 AM

Each calculation type can define configuration settings that are used to configure the calculation i.e. influences how the calculation is performed. Along with the calculation settings each calculation type can also define validation rules that validate the setting values. When an instance of the calculation type is validated all these validations for parameter values are also checked.


Spatial data handling

Last edited: 10/5/2017 11:51:42 AM

Spatial data stored for observations is handled differently by different calculation types. Table 1 describes the different approaches for handling spatial data in calculations.

Spatial data handling | Notes
Copy | The spatial data found in source observations is copied to the output without modification.
Modify | The spatial data of the source observations is modified (transformed)
Set empty | The spatial data of the output will be set to empty.

Table 1: Different approaches for handling spatial data


Generic calculation types

Last edited: 10/5/2017 11:51:22 AM

The Application Server comes with a set of generic calculation types that can be applied to many feature types. Each of these types is described in the following chapters.


Copy

Last edited: 10/5/2017 11:51:06 AM

The copy calculation type is used to simply create a copy of the observations of the source feature connected to its input pin.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit by pin, derived from feature connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to copy | Feature only. The copy template can copy any feature type. This pin is the defining pin | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include Erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False

Table 3: Configuration settings

If the calculation is the final calculation of the algorithm the used classifications of the source features or calculations has to be the used classification in the domain of the calculated feature.

Together with instantiating calculated features this calculation type can be used to create snapshots of a specific feature's observation data over time.


Data condensation: Significant value change

The data condensation: significant value change calculation type reduces the amount of observations by selecting only observations where the value of a specified parameter changed significantly in relation to the last significant observation's property value. A significant change in the parameter value is a change that exceeds a specific ε . ε can be a fixed value specified in the configuration settings or can be derived from the standard deviation.

The first observation of the source feature or calculation will always be present in the calculated feature.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit by pin, derived from feature connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to process | Features or calculations, Feature's type must have at least one numerical or quantity property | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Inspected property | Property | The property that will be processed to identify which observations will be copied to the output and which observations will be skipped. |
Epsilon definition | Enumeration | Options are: ·Fixed value ·Derived from standard deviation | 1
Epsilon fixed value | Numeric | Effective only if Epsilon definition is set to Fixed value. | 0
Standard deviation fraction | Numeric | Effective only if Epsilon definition is set to Derived from standard deviation. | 10

Table 3: Configuration settings

If the calculation is the final calculation of the algorithm the used classifications of the source features or calculations has to be the used classification in the domain of the calculated feature. If this is not the case the calculation will fail.

Epsilon definition Derived ε

If the Epsilon definition configuration setting is set to Derived from standard deviation the ε used in the algorithm to identify significant value changes is derived from the standard deviation. See figure 1 for the formal definition of this deviation.

Figure 1: Deriving ε using the standard deviation and the standard deviation fraction configuration setting

Algorithm

The algorithm sequentially reads values of the specified property in all observations and checks if the difference to the last significant value is greater than ε. The first observation of a feature is always considered as significant. If the configuration setting Include last observation is true the last observation is always added to the output. See figure 2 for a formal specification of the algorithm.

Figure 2: The algorithm used to identify significant observations


Data condensation: Simple

Last edited: 10/5/2017 11:51:06 AM

The aim of data condensation is to create a set of observations that has significant smaller count than the observation set of the source feature but is still a reasonable representation of the real world phenomenon. Condensing data might be a good choice to get a reasonable sized set of observations that can be manually examined, presented graphically, or that can be further processed with reasonable performance.

The data condensation: simple calculation type provides very simple condensation algorithms that do not find a reasonable representation of the real world phenomenon in all cases, but are fast in terms of processing and prove to be useful if you can make certain assumptions on the characteristics of your source data.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit by pin, derived from feature connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to process | Features or calculations | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Condensation algorithm | Enumeration | Options are: ·Each n-th ·One per interval | 100
Include last observation | Boolean | Setting for the Each n-th condensation algorithm. If true the last observation of the source feature or calculation will always be added to the output | false
n-th | Numeric | Setting for the Each n-th condensation algorithm. Defines which observations of the source feature are picked. Must be a integer number greater or equal 1. | 10
Start timestamp | Date & time | Setting for the One per interval condensation algorithm. Defines the start time from which intervals are calculated. Can be left undefined. |
Time interval | Time span | Setting for the One per interval condensation algorithm. Defines the time span. Must be a time span greater than 0. | 24:00:00

Table 3: Configuration settings

If the calculation is the final calculation of the algorithm the used classifications of the source features or calculations has to be the used classification in the domain of the calculated feature. If this is not the case the calculation will fail.

Each n-th Algorithm

This algorithm simply takes each n-th observation of the source feature or calculation. Figure 1 shows a formal specification of the algorithm.

The configuration setting n-th influences the condensation ratio defined as NumberOfGeneratedObservations / NumberOfOriginalObservations. Higher values for n-th produce smaller condensation ratios. If set to true the configuration setting include last observation will always add the last observation of the source feature or calculation to the output.

Figure 2 shows an example output of the Each n-th algorithm.

The each n-th algorithm is useful when dealing with observations recorded at a high and regular sampling rate but with little changes in the observed property values and if the exact time when a property value changed is not important.

Figure 1: Selection of output observations by the Each n-th Algorithm.

Figure 2: Example of Each n-th algorithm

One per interval

This algorithm will choose only one observation per interval. The intervals are defined by the Start timestamp and Time interval configuration setting by using the algorithm shown in figure 3. Figure 4 shows which observation is picked from all the observations found in an interval.

This algorithm is useful if you have observations at a high and irregular sampling rate with little changes in the observed property values and if the exact time when a property value changed is not important.

Figure 3: Specification of the intervals for the on per interval algorithm

Figure 3: Picking one observation per interval

Examples for picking an observation from an interval:

·If the interval contains observations with sampling timestamps {t1, t2, t3, t4, t5}, t3 will be chosen.

·If the interval contains observations with sampling timestamps {t1, t2, t3, t4}, t2 will be chosen.

·If the interval contains observations with sampling timestamps {t1, t2}, t1 will be chosen.

·If the interval contains observations with sampling timestamps {t1}, t1 will be chosen.


Merge

Last edited: 10/5/2017 11:51:08 AM

The merge calculation type is used to merge the observations of two or more features of the same feature type into one feature of that same type. If two or more source features contain observations with the same sampling timestamp only the observation of the first source feature will be present in the calculated feature.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit by pin, derived from features connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint, Notes | Multiplicity (Min,Max)
1 | Features to merge | Features or calculations, Same feature types, same spatial reference system. This is the defining input pin. | 2,*

Table 2: Input pins

Configuration | Type | Notes | Default value
Include Erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | True

Table 3: Configuration settings

If the property structure used in the observations of the source features or calculations uses classifications the used classifications must be the same for all source features or calculations. If the calculation is the final calculation of the algorithm the used classifications of the source features or calculations has to be the used classification in the domain of the calculated feature.

If the source features or calculations have observations with the same sampling timestamp the output of this calculation will take the observation of the first feature or calculation and skip the observations of other feature or calculations with the same sampling timestamp. The number of observations in the output is therefore smaller or equal to the sum of all observations in all source features or calculations.


Property filter: Boolean

Last edited: 10/5/2017 11:51:06 AM

Filtering will take a subset of the source features observations where the value of a specified Boolean property matches the provided comparison value. If properties are not on level 1, All or Any and None can be used.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit, derived from feature connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to filter | Any type that has a Boolean property. | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Property to compare | Property | Property whose values will be compared against the comparison value. Must be defined. |
Comparison value | Boolean | The comparison value. Only observations where the selected property's value matches this comparison value will be included in the output. | true
Include null values | Boolean | If true observations where the selected property's value is null will always be included in the output. If selected property is not on level o of the property structure this setting has no effect. | false
Grouping function | Enumeration | All, Any, None | All

Table 3: Configuration settings


Property filter: Datetime

Navigation: Application Server > Processing > Calculated features > Calculation types > Generic calculation types >

Property filter: Date time

Last edited: 10/5/2017 11:51:06 AM

Filtering will take a subset of the source features observations where the sampling timestamp property is within provided start and end date. If properties are not on level 1, All or Any and None can be used.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit, derived from feature connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to filter | Any type. | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Start date | Datetime | Start date of a observation sampling time stamp. Optional. | DateTimeOffset.MinValue
End date | Datetime | End date of a observation sampling time stamp. Optional. | DateTimeOffset.MaxValue
Grouping function | Enumeration | All, Any, None | All

Table 3: Configuration settings


Property filter: Classification

Last edited: 10/5/2017 11:51:06 AM

Filtering will take a subset of the source features observations where the value of a specified classification property matches the provided comparison value. If properties are not on level 1, All or Any and None can be used

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit, derived from feature connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to filter | Any type that has a Boolean property. | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Property to compare | Property | Property whose values will be compared against the comparison value. Must be defined. |
Comparison value | Classification | The comparison value. Only observations where the selected property's value matches this comparison value will be included in the output. Must be defined |
Include null values | Boolean | If true observations where the selected property's value is null will always be included in the output. If selected property is not on level o of the property structure this setting has no effect. | false
Grouping function | Enumeration | All, Any, None | All

Table 3: Configuration settings


Property filter: Numerical

Last edited: 10/5/2017 11:51:06 AM

Filtering will take a subset of the source features observations where the value of a specified numeric property matches the provided comparison value with the provided comparison operator. If properties are not on level 1, All or Any and None can be used

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit, derived from feature connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to filter | Any type that has a numeric property. | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Property to compare | Property | Property whose values will be compared against the comparison value using the selected comparison operator Must be defined. |
Comparison operator | Enumeration | = exact match < property value is lower than comparison value < property value is lower or equal than comparison value > property value is greater than comparison value ≥ property value is greater or equal than comparison value ≤ property value is less or equal than comparison value != property value is not equal comparison value Between property value is between comparison value 1 and comparison value 2 (including comparison value 1 and 2) | =
Comparison value 1 | Numeric | The comparison value. Only observations where the selected property's value matches this comparison value will be included in the output. Must be defined for all comparison operators |
Comparison value 2 | Numeric | Must be defined if comparison operator is between |
Include null values | Boolean | If true observations where the selected property's value is null will always be included in the output. If selected property is not on level o of the property structure this setting has no effect. | false
Grouping function | Enumeration | All, Any, None | All

Table 3: Configuration settings


Property filter: Quantity

Last edited: 10/5/2017 11:51:06 AM

Filtering will take a subset of the source features observations where the value of a specified numeric property matches the provided comparison value with the provided comparison operator. If properties are not on level 1, All or Any and None can be used.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit, derived from feature connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to filter | Any type that has a numeric property. | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Property to compare | Property | Property whose values will be compared against the comparison value using the selected comparison operator Must be defined. |
Comparison operator | Enumeration | = exact match < property value is lower than comparison value < property value is lower or equal than comparison value > property value is greater than comparison value ≥ property value is greater or equal than comparison value != property value is not equal comparison value Between property value is between comparison value 1 and comparison value 2 (including comparison value 1 and 2) | =
Comparison value 1 | Numeric | The comparison value. Only observations where the selected property's value matches this comparison value will be included in the output. Must be defined for all comparison operators |
Comparison value 2 | Numeric | Must be defined if comparison operator is between |
Comparison value units | Unit | Must be defined |
Include null values | Boolean | If true observations where the selected property's value is null will always be included in the output. If selected property is not on level o of the property structure this setting has no effect. | false
Grouping function | Enumeration | All, Any, None | All

Table 3: Configuration settings

The comparison of values is done using the provided comparison value unit. I.e. the property values in the source observations can be in any unit.


Random data

Last edited: 10/5/2017 11:51:06 AM

The random data calculation does not operate on data of source features but as the name implies just creates observations with random data. The random data calculation can create observations that conform to the observation property structure of any feature type.

Characteristic | Description
Supports incremental execution | No
Output typing | Implicit by setting, derived from feature connected to input pin 1
Locking of source features | No locking
Spatial data handling | Since this calculation type invents new data there is no need for spatial data handling. The output created from this calculation will have empty spatial data.

Table 1: Calculation brief

No

Name

Type, Constraint

Multiplicity (Min,Max)

No input pins defined

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, some of the generated calculations will be erroneous. Which observations are created as erroneous observations is decided by a random algorithm | False
Feature type | Enumeration | Defines the output format of the calculation |
Number of observations | Numeric | Defines how many observations will be created | 100
Start time stamp | Date&Time | Sampling timestamp of the first created observation. | 2000-01-01 00:00:00.0 (Server's time zone)
Use randomized sampling time stamps | Boolean | If true the sampling timestamps for generated observations will be generated randomly. See below for details. | True
Increment | Time span | Used for generating sampling timestamps for the generated observations. See below for details. | 01:00:00.0
Maximum collection members | Numeric | Defines the maximum number of members that will be generated for each collection in the property structure of the output. Note that the actual number of created members is a randomly chosen number between 0 and this setting's value. | 5

Table 3: Configuration settings

A calculation of this type will produce as many observations as defined by the configuration setting Number of observations. The observations' base data and property values in the observations' type specific data will be filled with random values as described below.

Note that the generated observations do not necessarily conform to the validation rules that are in place for the feature.

The sampling timestamps of the generated observations are generated by the algorithm shown in figure 1. The algorithm uses the start time stamp, increment and use randomized sampling timestamps settings. If use randomized sampling timestamps is set to false the sampling timestamps of observations will form a regular raster, if set to true the actual sampling timestamp for generated observations will be slightly varied.

All generated observations will not be erroneous and will have no result timestamp.

Figure 1: Generation of sampling timestamps for generated observation

The values of the properties in the property structure used for the observations' type specific data are filled with data as shown in table 1. If the property structure includes collections each collection will be filled with a randomly chosen number of property structures between 0 and the number defined with the configuration setting Maximum collection members. The property values of properties in collections will again be filled with values as described in table 1.

Property type | Data filled
Numerical | Random number between -1000 and 1000
Quantity | Random value between -1000 and 1000 in a randomly chosen unit (all property values will use same randomly chosen unit)
Boolean | Randomly true or false
Classification | Random element out of the set of elements of the used classification of the calculated feature
multi-select classification | No elements will be selected
Feature link | No value
Binary | No value
Date & time | Random date & time between 1950-01-01 00:00:00.0 and 2050-01-01 00:00:00.0 in the servers time zone
URL | No value

Table 1: Values assigned to properties of different property type.


Relative values conversion

Last edited: 10/5/2017 11:51:06 AM

When not the absolute value in an observation but the value change of a property in an observation is the subject of interest then the relative values conversion can be used to calculate the value change relative to a reference value. The reference value can be indirectly chose by specification of a reference timestamp. This calculation type supports the calculation of up to five properties at the same time.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit, derived from features connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to process | Features or calculations, must have at least one numerical or quantity property. | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Property to process 1 | Property | Property of type numeric or quantity. Mandatory. Defines a property that will be converted to a relative value. |
Property to process 2 | Property | Property of type numeric or quantity. Optional. Defines a property that will be converted to a relative value. |
Property to process 3 | Property | Property of type numeric or quantity. Defines a property that will be converted to a relative value. |
Property to process 4 | Property | Property of type numeric or quantity. Defines a property that will be converted to a relative value. |
Property to process 5 | Property | Property of type numeric or quantity. Defines a property that will be converted to a relative value. |
Reference timestamp | Date & Time | Calculation is done relative to the first observation with a sampling timestamp ≥ this reference timestamp. | 0000:01-01 00:00

Table 3: Configuration settings

If any of the properties to process are quantities the values for this property will be converted to the first unit used for this quantity.

If the calculation is the final calculation of the algorithm the used classifications of the source features or calculations has to be the used classification in the domain of the calculated feature.

The reference timestamp is used to specify which observation will be used as the reference observations. The actual reference observation is the furst observation with a sampling timestamp ≥ the chosen reference timestamp. If there is no observation ≥ this reference timestamp the recalculated values will be null. The default for this setting is 0001-01-01:00:00 which will always chose the first observation as reference timestamp. The values of all chosen properties will be recalculated relative to the specified reference observation. Figure 1 shows the formal definition of the relative values conversion algorithm.

Figure 2 to 4 shows examples of the effect the relative values conversion algorithm has on a set of data depending on the chosen reference observation.

Figure 1: Relative values conversion algorithm

Figure 1: Relative values conversion example 1

Figure 1: Relative values conversion example 2

Figure 1: Relative values conversion example 3


Spike filter

Last edited: 10/5/2017 11:51:08 AM

Automatically detects spikes in data and copies only observations to the output that are not considered as spikes. This simple spike filter is based on two configuration values the Maximum value fluctuation and the Maximum observation count in spike. This spike filter is meant to be used for series of data that may include bursts of erroneous data.

Figure 1, 2 and 3 show examples of the application of this spike filter to a series of values.

Characteristic | Description
Supports incremental execution | No
Output typing | Implicit
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to process | Features or calculations, at least one numeric or quantity property. | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Property to calculate | Property | The property that is used for the spike filtering. |
Maximum value fluctuation | Numeric | Changes beyond this value mean spike, if value returns inside this range after distance specified by the next parameter |
Maximum observation count in spike | Numeric | Number of observations to look for the value to return to its normal range after spike-like change was detected by the previous setting | 1

Table 3: Configuration settings

If the calculation is the final calculation of the algorithm the used classifications of the source features or calculations has to be the used classification in the domain of the calculated feature.

Figure 1: Spike filter example 1

Figure 2: Spike filter example 2

Figure 3: Spike filter example 3


Statistical values advanced

Last edited: 11/8/2017 9:31:50 AM

The statistical values 2 calculation type calculates a wide range of statistical values of a specific property: Minimum, maximum, average, sum, count, median, standard deviation, modus, a lower and an upper quantil. The lower and upper quantil can be specified as a configuration setting. The calculation type supports different calculation modes that define how many observations will be generated, how values for these observations are calculated, and how sampling timestamps for the output calculations are generated.

Note that this calculation type is much slower than the statistical values 1 calculation type.

Characteristic | Description
Supports incremental execution | No
Output typing | Explicit, output format: Statistical overview 2
Locking of source features | Observation modification, observation deletion
Spatial data handling | Set empty

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to process | Feature or calculation, must have at least one numeric or quantity property. | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Property to calculate | Property | The property from which the statistical values will be calculated |
Calculation mode | Enumeration | Defines which observations of the feature or calculation at input pin 1 are used to calculate the statistical values and how many output observations will be created. Following options are available: ·Total ·Sliding window ·Running ·Time blocks | Total
Lower quantil |  | A value between 0 and 1, specifies the calculated upper quantil | 0.25
Upper quantil |  | A value between 0 and 1, specifies the calculated lower quantil | 0.75
Sliding window size | Time span | Effective for calculation mode sliding window. | 24:00:00
Start timestamp | Date & Time | Effective for calculation mode time blocks. Is used to build up the time blocks for which statistical values will be calculated. | 2012-01-01 00:00:00 in Servers time zone
Time block interval size | Time span | Effective for calculation mode Time blocks. Defines the size of one time block. | 24:00:00

Table 3: Configuration settings

The properties in the property structure for observations of the feature type Statistic advanced are of property type numeric. I.e. the statistical values calculated by this calculation type are stored dimensionless. If the result of a calculation of this type is persisted as calculated feature the user can set a descriptive unit as display setting.

If the property to calculate is a property of type quantity the values of this property in all observations are not automatically converted, before the statistical values are calculated, use a unit conversion calculation before the statistical calculation if your feature stores property values in different units.

Calculation mode total

The calculation mode total will calculate standard deviation, median, quantil 1 and quantil 2 for all observations in the feature or calculation connected to pin 1. Using this calculation mode will therefore result in exactly one output observation. The sampling timestamp for that output observation will be the date & time of the last source ovservation.

Figure 1 gives a formal definition of this calculation mode. Note that if the property's value is not defined (null) in a specific observation, it will not be used for calculation of statistical values.

Figure 1: Formal definition of the calculation mode total

Calculation mode sliding window

The calculation mode sliding window will create the same number of output observations as found in the feature or calculation connected to pin 1. The sampling timestamps of the output observations will be the same as the sampling timestamp of the input observations.

For each output observation this calculation mode will calculate the statistical values from all observations that are within a specified time window before (and including) the sampling timestamp of the created observation. The formal definition of the set of observations that are used to calculate the statistical values for a specific output observation is shown in figure 2. Figure 3 shows the actual calculation of the statistical values.

Figure 2: Definition of source observations for calculation modes sliding window and running

Figure 2: Calculation for sliding window

Calculation mode running

The calculation mode running is a special case of the sliding window algorithm with an sliding window of infinite size. See figures 2 and 3 for a formal definition of the observations used to calculate a specific output observation and for a specification of the calculation of statistical values.

Calculation mode time blocks

This calculation mode will divide the observations in blocks of same time length and calculate the statistical parameters for each block. Time blocks are defined by a start timestamp and a time interval. Figure 3 shows the formal specification of the time intervals. The sampling timestamp of the observation created for a specific interval will be the arithmetic mean of the intervals lower and upper boundary. See figure 4 for a formal specification on the generation of the sampling timestamp.

The calculation of the statistical values is done analogous to the sliding window calculation mode.

Figure 3: Specification of time intervals

Figure 2: Definition of sampling time stamps in calculation mode time blocks


Statistical values simple

Last edited: 11/8/2017 9:31:50 AM

The statistical values 1 calculation type calculates the minimum, maximum, average, sum and count of a specific property. The calculation type supports different calculation modes that define how many observations will be generated, how values for these observations are calculated, and how sampling timestamps for the output calculations are generated.

Characteristic | Description
Supports incremental execution | No
Output typing | Explicit, output format: Statistic simple
Locking of source features | Observation modification, observation deletion
Spatial data handling | Set empty

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to process | Feature or calculation, must have at least one numeric or quantity property. | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Property to calculate | Property | The property from which the statistical values will be calculated |
Calculation mode | Enumeration | Defines which observations of the feature or calculation at input pin 1 are used to calculate the statistical values and how many output observations will be created. Following options are available: ·Total ·Sliding window ·Running ·Time blocks | Total
Sliding window size | Time span | Effective for calculation mode sliding window. | 24:00:00
Start timestamp | Date&time | Effective for calculation mode time blocks. Is used to build up the time blocks for which statistical values will be calculated. | 2012-01-01 00:00:00 in Servers time zone
Time block interval size | Time span | Effective for calculation mode Time blocks. Defines the size of one time block. | 24:00:00

Table 3: Configuration settings

While this calculation type only calculates a limited number of statistical values it is much faster than the Statistical values advanced calculation type.

The properties in the property structure for observations of the feature type Statistic simple are of property type numeric. I.e. the statistical values calculated by this calculation type are stored dimensionless. If the result of a calculation of this type is persisted as calculated feature the user can set a descriptive unit as display setting.

If the property to calculate is a property of type quantity the values of this property in all observations are not automatically converted, before the statistical values are calculated, use a unit conversion calculation before the statistical calculation if your feature stores property values in different units.

Calculation mode total

The calculation mode total will calculate minimum value, maximum value, average value, sum of all values and count of observations for all observations in the feature or calculation connected to pin one. Using this calculation mode will therefore result in exactly one output observation. The sampling timestamp for that output observation will be the date & time of the last source observation.

Figure 1 gives a formal definition of this calculation mode. Note that if the property's value is not defined (null) in a specific observation, it will not be used for calculation of statistical values. Therefore the calculated count is the count of observations where the selected property has a defined value. I.e. the count is not necessarily the same number as the observation count of the source feature or calculation.

Figure 1: Formal definition of the calculation mode total

Calculation mode sliding window

The calculation mode sliding window will create the same number of output observations as found in the feature or calculation connected to pin 1. The sampling timestamps of the output observations will be the same as the sampling timestamp of the input observations.

For each output observation this calculation mode will calculate the statistical values from all observations that are within a specified time window before (and including) the sampling timestamp of the created observation. The formal definition of the set of observations that are used to calculate the statistical values for a specific output observation is shown in figure 2. Figure 3 shows the actual calculation of the statistical values.

Figure 2: Definition of source observations for calculation modes sliding window and running

Figure 3: Formal definition of the calculation mode sliding window and running

Calculation mode running

The calculation mode running is a special case of the sliding window algorithm with an sliding window of infinite size. See figures 2 and 3 for a formal definition of the observations used to calculate a specific output observation and for a specification of the calculation of statistical values.

Calculation mode time blocks

This calculation mode will divide the observations in blocks of same time length and calculate the statistical parameters for each block. Time blocks are defined by a start timestamp and a time interval. Figure 3 shows the formal specification of the time intervals. The sampling timestamp of the observation created for a specific interval will be the arithmetic mean of the intervals lower and upper boundary. See figure 4 for a formal specification on the generation of the sampling timestamp.

The calculation of the statistical values is done analogous to the sliding window calculation mode. Figure 5 gives a formal specification.

Figure 3: Formal definition of the generation of time blocks for the calculation mode time blocks

Figure 4: Generation of the sampling timestamp for a

Figure 5: Calculation of statistical values in calculation mode time blocks


Time resampling: regular

Last edited: 11/8/2017 9:31:50 AM

The time resampling: regular calculation type will create a series of observations with virtual sampling timestamps and derived property values. The virtual sampling timestamps are defined by a start timestamp and a time increment defined in the calculation's configuration - it will therefore form a regular time raster. The property values in type specific data of the observations at these virtual timestamps is derived using the algorithm specified in the calculation's configuration.

Time resampling is used mostly for following purposes

·Resample to a regular time raster

·Condense or extend data amount (see also the data condensation calculation type for more advanced data condensation options)

Characteristic | Description
Supports incremental execution | No
Output typing | Implicit by pin, derived from feature connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Set empty

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to resample | Features or calculation results of any type | 1

Table 2: Input pins

Configuration

Type

Notes

Default value

Include erroneous

Boolean

If set to true, erroneous observations of the source feature or calculation will be processed.

False

Value deriving algorithm

Enumeration

Options are:

·Nearest neighbor

·Linear interpolation

·Averaging

Nearest neighbor

Start time stamp

Date&time with offset

Defines the first virtual sampling epoch for regular interval resampling.

2010-01-01 00:00.00 in servers local time zone

Time increment

Time span

Defines the time interval between two virtual sampling epochs for regular interval resampling

00:00:00

Maximum distance

Time span

Defines the maximum distance (time span) a virtual sampling epoch can have to its next original sample in order to create a virtual sampling epoch.

If there is no original sample within this distance the sampling timestamp will not be created. This applies to all interpolation algorithms.

0:00:23:59

Table 3: Configuration settings

The virtual sampling timestamps are generated using the given start time stamp ant the given time increment. Note that irrespective of the value set for the start timestamp virtual sampling timestamps will only be created between the source features first and last sampling timestamp. Figure 1 shows a formal definition of how virtual the sampling timestamps are generated.

Figure 1: Specification of virtual sampling timestamps

Nearest neighbor algorithm

The values for the properties are copied from the nearest original observation. This algorithm preserves values of all properties (of all types) of the nearest neighbor as well as collections of the nearest neighbor observation. See Figure 2 for a formal specification the nearest neighbor observation.

Figure 2; Specification of the nearest neighbor.

If the calculation is the final calculation of the algorithm the used classifications of the source features or calculations has to be the used classification in the domain of the calculated feature. If this is not the case the calculation will fail.

Linear interpolation algorithm

The values for properties of property type numeric and quantity are derived by linear interpolation of the property values of the previous and next observation. See figure 3 for a specification of the linear interpolation.

This value deriving algorithm has following limitations:

·All members of collections in the source property structure not be processed i.e. all collections in the calculated feature will be empty.

·All non numeric properties in the source property structure will be set to null

Figure 3: Specification of linear interpolation algorithm

Arithmetic mean algorithm

The values for properties of property type numeric and quantity are derived by calculating the arithmetic mean of all available values of these properties in observations of the source feature where the sampling timestamp is in the half open interval specified in Figure 4. Figure 5 shows how the average for a specific sampling timestamp is calculated. Property values that are null are not processed.

This value deriving algorithm has following limitations:

·All members of collections in the source property structure not be processed i.e. all collections in the calculated feature will be empty.

·All non numeric properties in the source property structure will be set to null

Figure 4: Specification of interval for the averaging algorithm

Figure 5: Calculation of a calculated observation's property value using the averaging algorithm


Time resampling: template

Last edited: 10/5/2017 11:51:08 AM

The Time template resampling calculation type type is similar to the time resampling calculation type, the only difference is that this calculation type will not create observations with virtual sampling timestamps based on a regular time raster, but based on the observations' sampling timestamps of another feature or calculation output. Therefore this calculation type can be used to create a calculated feature whose observation sampling timestamps are exactly the same as the sampling timestamps of observations of another feature.

Characteristic | Description
Supports incremental execution | No
Output typing | Implicit by pin, derived from feature connected to input pin 1
Locking of source features | Pin 1: Observation modification, observation deletion Pin 2: No locking
Spatial data handling | Set empty

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to resample | Flat observation property structure | 1,1
2 | Sampling timestamp template | Any feature type | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Value deriving algorithm | Enumeration | Options are: ·Nearest neighbor ·Linear interpolation ·Averaging | Nearest neighbor
Maximum distance | Time span | Defines the maximum distance (time span) a virtual sampling epoch can have to its next original sample in order to create a virtual sampling epoch. If there is no original sample within this distance the sampling timestamp will not be created. This applies to all interpolation algorithms. Must be defined. |

Table 3: Configuration settings

Note that only those timestamps from the sampling timestamp template feature will be used that are within the range. See Figure 1 for a specification of the virtual sampling timestamps

Figure 1: Specification of virtual sampling timestamps

Nearest neighbor algorithm

The values for the properties are copied from the nearest original observation. For details see the documentation of the nearest neighbor algorithm in time resampling: regular.

If the calculation is the final calculation of the algorithm the used classifications of the source features or calculations has to be the used classification in the domain of the calculated feature. If this is not the case the calculation will fail.

Linear interpolation algorithm

The values for properties of property type numeric and quantity are derived by linear interpolation of the property values of the previous and next observation. For details see the documentation of the linear interpolation neighbor algorithm in time resampling: regular.

Arithmetic mean algorithm

The values for properties of property type numeric and quantity are derived by calculating the arithmetic mean of all available values of these properties in the set of observations defined as shown in Figure 2. The specification of the actual calculation of the arithmetic mean is shown in figure 3

This value deriving algorithm has following limitations:

·All members of collections in the source property structure not be processed i.e. all collections in the calculated feature will be empty.

·All non numeric properties in the source property structure will be set to null

·Quantities are not converted automatically. Therefore the interpolation might be erroneous if the source observations use different units, use a unit conversion calculation before this calculation to prevent these errors.

Figure 2: Specification of the observations that are used to calculate the arithmetic mean.

Figure 5: Calculation of a arithmetic mean for an observation of the output.


Unit conversion

Last edited: 10/5/2017 11:51:08 AM

The unit conversion calculation type is used to convert the unit of quantity properties. This is especially useful if you have observations that use different units for the same property (over time) or if you just want to convert to another unit. This calculation type supports up to five conversion, i.e. up to five properties of type quantity can be converted to the chosen units.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit by pin, derived from features connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to convert | Features or calculations | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Source property 1 | Property | The property of property type quantity that will be converted. Must be defined. |
Destination unit 1 | Enumeration | The unit to which the property values of source property 1 will be converted. Must be defined. |
Source property 2 | Property | The property of property type quantity that will be converted. Optional. |
Destination unit 2 | Enumeration | The unit to which the property values of source property 2 will be converted. Optional. |
Source property 3 | Property | The property of property type quantity that will be converted. Optional. |
Destination unit 3 | Enumeration | The unit to which the property values of source property 3 will be converted. Optional. |
Source property 4 | Property | The property of property type quantity that will be converted. Optional. |
Destination unit 4 | Enumeration | The unit to which the property values of source property 4 will be converted. Optional. |
Source property 5 | Property | The property of property type quantity that will be converted. Optional. |
Destination unit 5 | Enumeration | The unit to which the property values of source property 5 will be converted. Optional. |

Table 3: Configuration settings

If the calculation is the final calculation of the algorithm the used classifications of the source features or calculations has to be the used classification in the domain of the calculated feature. If this is not the case the calculation will fail.


Zero reading correction

Last edited: 10/5/2017 11:51:08 AM

Observations in many different application domains use the zero reading markers to mark property values in observations as being not reliable. I.e. the changes to the last observation's property value are not considered to be changes that actually occurred on the phenomenon but changes that were introduced due to the used observation procedure. The zero reading correction calculation type can use these markers to correct the values of numerical columns according to these markers.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Implicit by pin, derived from features connected to input pin 1
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint | Multiplicity (Min,Max)
1 | Feature to correct | Features or calculations ·Source feature must have at least one logical property on level 0 ·Source feature must have at least one numerical ore quantity property on level 0 | 1,1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | False
Correction algorithm | Enumeration | Specifies the zero reading correction algorithm ·Copy last value (currently the only available type) | Copy last value
Logical property | Property | Zero reading indicator property. Type of property is Boolean. Must be defined |
Property to correct 1 | Property | Numerical or quantity property to be corrected. Must be defined. |
Property to correct 2 | Property | Numerical or quantity property to be corrected. Optional. |
Property to correct 3 | Property | Numerical or quantity property to be corrected. Optional. |
Property to correct 4 | Property | Numerical or quantity property to be corrected. Optional. |
Property to correct 5 | Property | Numerical or quantity property to be corrected. Optional. |

Table 3: Configuration settings

Figure 1: The zero reading correction algorithm for the copy last value correction

Figure 2: Example of a zero reading correction.

Figure 3: Example of a zero reading correction

If the calculation is the final calculation of the algorithm the used classifications of the source features or calculations has to be the used classification in the domain of the calculated feature. If this is not the case the calculation will fail.


Surveying

Last edited: 10/5/2017 11:51:42 AM

Calculation types in this chapter are useful in the area of surveying.


Point pair relation

Last edited: 10/5/2017 11:51:30 AM

The Point pair relation calculation type calculates some key figures that describe the spatial relation of two points on the surface of the earth that are continuously monitored. The two points are represented as features of feature type 3D movement.

Since the feature type 3D movement can only be located in projected coordinate systems and since the observations' X, Y; and Elevation properties are interpreted in the projected coordinate system the feature uses, this calculation uses trigonometry to calculate the key figures.

Characteristic | Description
Supports incremental execution | Yes
Output typing | Explicit: Point pair relation
Locking of source features | Observation modification, observation deletion
Spatial data handling | Copy

Table 1: Calculation brief

No | Name | Type, Constraint, Notes | Multiplicity (Min,Max)
1 | 3D Movement 1 | Features or calculations | 1, 1
2 | 3D Movement 2 | Features or calculations | 1, 1

Table 2: Input pins

Configuration | Type | Notes | Default value
Include Erroneous | Boolean | If set to true, erroneous observations of the source feature or calculation will be processed. | True
Search Epsilon | Numeric | Defines the search Epsilon in Seconds that is used to find a correlating observation, | 0

Table 3: Configuration settings

The calculation is performed on corresponding pairs of observations from two Features or calculations (Feature 1 connected to pin 1 and feature 2 connected to pin 2).

For each observation in Feature 1 the calculation searches for a corresponding observation in Feature 2. This is done by getting the observation in Feature 2 that is nearest to the observation in feature 1 (in terms of sampling timestamp) and that is in the specified Epsilon search environment of the sampling timestamp of the feature of Feature 1.

If no corresponding observation is found for an observation of Feature 1 the output will not contain an observation with that sampling timestamp.

Figure 1: Details about the calculation


%Text%

Navigation: Application Server > Processing >

In-Feature calculations

Last edited: 10/5/2017 11:51:06 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


%Text%

Navigation: Application Server > Processing >

Calculated properties

Last edited: 10/5/2017 11:51:06 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Presentation

Last edited: 10/5/2017 11:51:32 AM

The Application Server provides several presentation types to present data of features, observations or other elements managed by the Application Server. E.g. charts, maps view, reports etc.

Presentations of any type are generated based on a presentation definition that specifies layout and data shown in the presentation. The user can configure the presentation definition as needed.

When a presentation definition is executed the Application Server will usually create a client-independent meta format for the presentation and the client (like the Smart Client) will then render a visual presentation from this meta format. I.e. different clients might render the data in slightly different ways depending on the possibilities the client provides. Fore example a chart might look different in a mobile client than in the Smart Client.

Not that whenever a presentation definition is executed the Application Server will check if the user who executes has the appropriate permissions to read the data from the features that are used in this presentation definition. Only data for which the user has these permissions will be shown in the presentation.


Presentation templates

Last edited: 10/5/2017 11:51:32 AM

Presentation definitions can be stored for later or repeated execution, they are then called presentation templates. A presentation template can be created from every presentation definition.

Presentation templates are always linked to domains. A presentation template assigned to a domain is member of that domain and all of its subordinate domains, i.e. it is available for use in these domains.

While templates are bound to domains this does not limit the features you can chart with that domain. I.e. even if a feature is not member of the domain in which the template resides you can still chart the feature with that template, provided you have read rights to the domain and the feature.

The Application Server allows you to create personal and public presentation templates. Personal presentation templates are only visible by the user who created them, public templates are visible to all users.

Every user can create create, modify or delete his personal presentation templates. To create, modify or delete public presentation templates you need the domain permission Manage presentation templates (9).

Personal templates can be transformed to public templates, if the Manage presentation templates (9) domain permission is granted on the domain the template is bound to.

Public presentation templates can be transformed to personal presentation templates if the Manage presentation templates (9) domain permission is granted on the domain the template is bound to.


Observation filter

Last edited: 10/5/2017 11:51:32 AM

Presentation definitions can include an observation filter that allows you to define which observations shall be shown in the presentation.

The filter can be defined as a static or as a dynamic time span based on the observations sampling timestamp. If a presentation definition is persisted as presentation template the observation filter will also be part of the presentation template.


Charting

Last edited: 10/5/2017 11:51:08 AM

The application server provides several presentation types that are subsumed under the term charting. Charting allows the graphical display of observation data in different ways. Charting is useful for picturing data in ways that allow for quick examination and nice presentation of data, on screen as well as in printed form.

A common characteristic of charts is that they are not drawn in scale, i.e. if you generate a chart and print it on paper there is no control on how many millimeters one unit is in the printout.


Chart definition

Last edited: 10/5/2017 11:51:08 AM

As with all other presentations generated by Redbex charts are also generated based on a definition in this case the chart definition. The chart definition specifies what data is charted and how that data is charted.

The options for defining the layout and content of a chart can be logically structured into the sections described in table 1.

Definition | Description
Chart configuration | Settings that affect the chart as a whole.
Data filter | Filters the observations of features connected to pins, and therefore limits the number of observations shown in the chart.
Pins | Pins are the points where data (features or observations) are bound to the chart definition. On chart can have one or more pins and each pin connects one or more features. The chart type might restrict the maximum number of pins or features connected to one pin. Each pin has its own ping configuration.

Table 1: Logical structure of a chart definition


Chart configuration

Last edited: 10/25/2017 8:05:20 AM

The Chart configuration is a UConfiguration that mainly defines the layout of the chart.

Besides some settings common to all chart types (see table 1 to 3) each chart type will add its own settings to this UConfiguration. For these chart type specific settings refer to the documentation of the chart type.

Setting | Description
Title | A text setting defining a text template used as header above the chart. See below for a list of supported markup variables. Default: <empty>
Sub title | A text setting defining a text template used for a sub title and displayed directly beneath the title. See below for a list of supported markup variables. Default: <empty>
Header line | A text setting defining a text template used as header line directly above the chart. See below for a list of supported markup variables. Default: <empty>
Footer line | A text setting defining a text template used as footer line directly beneath the chart. See below for a list of supported markup variables. Default: <empty>
Show erroneous | Boolean setting that defines if set the chart will show erroneous observations. If not set erroneous observations will not be included. Default: false
Highlight erroneous | Boolean setting that defines if erroneous observations will be highlighted in the chart. Only effective of course if Show erroneous is set. Default: false
Highlight zero readings | Boolean setting that defines if observations that are marked as zero reading are highlighted in the chart. Default: false
Show observation filter | Boolean setting that defines if a textual representation of the chart definition's observation filter is displayed on the chart.

Table 1: Common Chart settings available in all chart types

Setting | Description
Show legend | Boolean setting that defines if a legend will be shown or not. Default: false
Legend location | Enumeration setting that defines that defines where the legend will be shown in the chart. Options are left, right, top or bottom. Note that the the rendering logic might limit the number of legend entries. Default: Top
Show units | Boolean setting that defines if units of the time series will be shown in the legend entries. Default: false

Table 2: Legend settings available with all chart types

Setting

Description

Date format

Text setting defining the date & time format string that is used to display date & time values on the chart (if any). If this format string is empty it will default to the format string d .

Default: d

Date time conversion

Defines how date time offset values are converted to date time values used in the chart.

·Strip off: The offset part of date time offset values will just be stripped, no conversion will be applied. Use this option if all your charted data was recorded with reference to the same time zone.

·Time zone conversion: Date time offset values will first be converted to the given time zone (see below) and after that the offset will be stripped off. Use this option if your date time offset values were recorded with reference to different time zones.

·Offset conversion: Date time offset values will firt be converted to the given offset (see below) and after that the offset will be stripped off. Use this option if you want to present data without shifts introduced by daylight saving time etc.

Time zone

Defines the timezone to which all charted date time offset values will be converted before the offset is stripped off.

The selection list includes all time zones that are made available by the operating system of the Application Server.

Default: Timezone of the Application Server

Offset [min]

Numeric setting defining a time offset in minutes to be used for the Offset conversion (see Date time conversion setting). This option is only available if the Date time conversion is set to Offset conversion.

Default: Time offset of the Application Server when the chart definition was created.

Naming of series

Enumeration that defines defines how series of data are named. Names of series are used in different places, e.g. in the chart legend.

Text template for series name

Text setting that defines a Text template used for naming series of data. This setting is only available if the Naming of series setting is set to Text template.

Additional to the common markup variables this text template allows following variables and classes

·FeatureType

·FeatureName

·FeatureSubtype.Name

·FeatureSubtype.Description

Table 3: Miscellaneous settings available with all chart types

The settings for title, subtitle, header line and footer line are text templates that can use additional markup variables as shown in table 4. E.g. you can use {{pins[0].sources[0].features[0].Name}} to reference the name of the first feature on the first pin.

Property | Description
Pins | Collection of pin markup objects of class pin representing the pins defined for the chart. (See table
Filter | A class representing the currently used observation filter.

Table 4: Additional text template markup variables available for title, subtitle, header line and footer line in chart templates.

Property | Description
Name | Name of the pin
Sources | Collection of source bound to the pin, represented as pin object (see table 6)

Table 5: The pin class used in text templates

Property | Description
Name | Name of an object bound to a pin
Description | Description of an object bound to a pin
Features | Collection of pin objects representing the features the source expands to.

Table 6: The pin object class used in text templates

Property | Description
From | Date time value
To | Date time value

Table 7: The filter object class used in text templates


Pins

Last edited: 10/5/2017 11:51:08 AM

A pin is where features are bound to a chart definition. The chart type defines how many pins a user can add to a chart definition and it also defines how many features can be connected to a single pin. Each pin has a UConfiguration. Pins and the associated UConfiguration are stored with the chart definition.

A pin is always typed with a feature type. Typing can be defined by the chart type or can be a setting of the pin. A pin can therefore connect features of one specific feature type only. If typing is a pin setting the chart type may restrict the feature types that can be used by defining characteristics a feature type must have. E.g. feature types with at least one numeric property on the first level of the observation property structure.

Charts support two different types of pins. Regular pins and Report pins. The user can connect features only to regular pins. Report pins are used by the reporting engine to dynamically create charts for a series of feature.

Setting | Description
Color | A single line of text printed as chart header above the chart. Default: Black
Drawing style | A single line of text printed directly beneath the header Default: Line
Line style | A single line of text printed above the chart Default: Solid
Line thickness | A single line of text printed below the chart Default: Thin
Show points | Defines if a symbol is shown at each data point Default: True
Point symbol | Defines if a textual representation of the chart definition's observation filter is displayed on the chart. Default: Circle
Point size | Defines if the chart will show observations marked as erroneous or not. Default: Small
Hide from legend | If set, contents of this pin will not added to the chart legend Default: false
Invert value | Inverts the charting values for all data connected to this pin. I.e. each charted value is multiplied by -1 before it is charted Default: false

Table 1: Common settings available for all pins


Connection settings

Last edited: 10/5/2017 11:51:08 AM

A chart definition uses pins connect features to the chart definition. Each connection between a pin and a feature has its own UConfiguration that is defined by the chart type.

Some Settings available in the UConfiguration of a connection are also available as settings in the UConfiguration of the pin the connection belongs to. In this case the Setting on the connection will override the setting on the pin if the value of the setting is not null.

For Boolean settings the setting on the pin and the setting on the connection are combined with a logical OR.

Setting | Description
Color | A single line of text printed as chart header above the chart. Default: <N/A>
Drawing style | A single line of text printed directly beneath the header Default: <N/A>
Line style | A single line of text printed above the chart Default: <N/A>
Line thickness | A single line of text printed below the chart Default: <N/A>
Point symbol | Defines if a textual representation of the chart definition's observation filter is displayed on the chart. Default: <N/A>
Point size | Defines if the chart will show observations marked as erroneous or not. Default: <N/A>
Hide from legend | If set, contents of this pin will not added to the chart legend Default: False
Invert value | Inverts the charting values for all data connected to this pin Default: False

Table 1: Common settings available for all connections


Value over time

Last edited: 10/5/2017 11:51:22 AM

The chart type Value over time shows the values of properties in an observation property structure over time (using the sampling timestamp of the observation). The chart can picture observation data from any number of features of any type as long as the observation property structure contains a numeric or quantity property on level 0.

When displaying quantity properties the chart assumes that the values of the shown property are all expressed in the same unit. The unit is derived from the first shown observation. If a feature contains data in different units you need to process the data first.

When displaying numeric properties the unit displayed in the chart is derived from the feature property settings for the property drawn.

This chart type allows any number of pins typed with different feature types, each pin can connect any number of features of the same feature type. Each feature connected to a pin is presented as separate time series.


Chart configuration

Last edited: 10/5/2017 11:51:46 AM

The global settings that affect the layout of the chart as a whole. These settings do not influence what is drawn but just how things are drawn. Following tables describe the settings available for this chart type (additional to the settings available for all chart types).

Setting | Description
Show legend | Defines if a legend will be shown or not. The legend will contain entries for all time series, that are not hidden. Default: false
Legend location | Defines where the legend will be shown in the chart. Options are left, right, top or bottom.
Show units | If true the units of the time series will be shown in the legend entries. Units are derived from the display settings of numeric properties or from the first value of a series of quantity properties. Default: false

Table 1: Additional Legend settings available for this chart type

Setting | Description
Coloring scheme | Defines how time series are colored. You can choose from a predefined list of options ·Use color from pins and features ·Use color palette
Naming of series | This setting defines how the name of a time series is displayed (e.g. in legend). You can choose from a predefined list of options. ·Feature type + feature + property ·Feature + property ·Property ·Text Template
Naming text template | A text template that can be used to define the naming of series. Only effective if Naming of series is set to Text template.

Table 2: Additional miscellaneous settings available for the chart type

Setting | Description
Grid Color | Color setting that specifies the color of grid lines Default: No color (grid will not be shown)
Show horizontal grid lines | Boolean setting that defines if horizontal grid lines (parallel to X-Axis) are shown Default: false
Show vertical grid lines | Boolean setting that defines if vertical grid lines (parallel to Y-Axis) are shown Default: false

Table 3: Settings in the Grid group defined by this chart type

The value over time chart type allows the definition of up to 10 sub-graphs. Each sub-graph can be configured separately. Table 4 shows the settings available for each sub-graph. Each sub-graph contains settings for the left and right Y axis of that sub-graph. These settings are described in Table 5.

The setting Alternating colors is a Boolean setting that defines if the background color of each second sub-graph shall be different, so that sub-graphs can be more easily distinguished.

Setting name | Description
Name | Text setting that defines the name of the sub-graph. This name will be shown on the Y axis of the sub-graph. Default: Subgraph <n>
Relative height | Numeric setting that defines the height of the sub-graph. The height of the sub-graph in the rendered chart equals a percentage of the total chart height. This percentage is calculated by dividing the specified height value with the sum of all height values defined for sub-graphs that have associated pins. Minimum value: 1 Default: 1
Settings for left Y axis | See Table 5
Settings for right Y axis | See Table 5

Table 4: Global chart settings available for each of the 10 sub-graphs

Setting name

Description

Axis name

Text setting that defines the name of the Axis.

Logarithmic scaling

Boolean setting that defines if this chart axis will use logarithmic scaling.

Default: false

Axis Color

Color setting that defines the color in which the axis is drawn.

Default: Black (RGB: 0,0,0)

Scaling Method

Enumeration setting that defines how the axis is scaled, i.e. how the minimum and maximum value shown on the axis are determined. Following options are available:

·Fixed: Uses the settings scaling minimum value and scaling maximum value to specify the scaling.

·Min-Auto: Uses the setting scaling minimum value for the lower boundary of scaling. The upper boundary is automatically determined based on the time series that are bound to the axis..

·Auto-Max: Uses the setting scaling maximum value for the upper boundary of scaling. The lower boundary is automatically determined based on the time series that are bound to the axis..

·Minimum interval: Uses the settings scaling minimum value and scaling maximum value to specify the scaling. If however the time series contain data that is out of these bounds the scaling will be automatically adapted.

Scaling Min value

Numeric setting that defines the minimum value shown on this axis (only effective for some specific values of the Scaling Method setting)

Scaling Max value

Numeric setting that defines the maximum value shown on this axis (only effective for some specific values of the Scaling Method setting)

Table 5: Global chart settings available for configuring

Setting name | Description
Time axis labels | Enumeration setting that defines how the labels on the time axis (X-axis) are displayed. Simple: Standard way of showing date & time values. Smart: A more sophisticated way of showing time-labels, especially useful if the chart covers a long time range. Default: Simple
Scaling | Enumeration Setting that defines the scaling (i.e. the minimum and maximum value shown on the X-axis). ·Automatic: Will scale the X-axis according to the data displayed. ·Use observation filter: Will use the time-boundaries of the observation filter.

Table 6: Settings in the UConfiguration's Time axis group

Besides data where for each point in time the chart shows the corresponding value on the chart's Y-axis, the time chart can also show observations of features as events, i.e. it can show the sampling and result time stamp of observations as vertical lines or rectangles across the whole Y-range of the chart. The UConfiguration's Events group is used to configure the display of events. You can define up to 3 feature's whose observations will be shown as events. Table 7 summarizes the settings available for each of these 3 features.

Setting name | Description
Event feature | Feature setting that is used to define the feature whose observations shall be shown as event.
Event name property | Property setting used to select a property of the feature-type's observation property structure that will be used to label the event in the chart. You can select any level 0 string property of the observation property structure. If null, the chart will not show any textual description of the event.
Event class property | Property setting used to select a property of the feature-type's observation property structure that will be used to classify the events. You can select any level 0 classification property of the observation property structure. The chart will display the events in a color according to that classification.

Table 7: Settings in the UConfiguration's Events group


Pin configuration

Last edited: 10/5/2017 11:51:30 AM

The value over time chart type allows the definition of any number of pins. Each pin has its own settings described in the following.

Setting | Description
Sub-graph assignment | Defines on which sub-graph the data of features connected to that pin will be displayed. You can choose from the ten predefined subgraphs. N
Y-Axis assignment | Defines if the time series resulting from feature connections to this pin are drawn against the left or the right Y-Axis,

Table 1: Settings for pins

For each pin you can define layout settings that will apply to all time series resulting from features connected to that pin. These settings are only respected if the global chart setting time series coloring defines so.

If layout settings are defined directly on a connection they will overwrite the settings defined on the pin. If the layout settings are not defined on the pin and also not defined on the connection the system will try to get the layout settings from the display settings associated with the charted property. If the system cannot find any defined layout setting it will choose default values.

Setting | Description
Color | Defines the color of the time series
Line style | Defines the line style for the time series.
Line thickness | Defines the line thickness of the time series.
Symbol | Defines the symbol used to depicture data points
Symbol size | Defines the size of the symbol
Drawing style | Defines how time series are charted. You can choose form a list of predefined options
Hie from legend | Can be used to hide specific time series from the legend.
Invert values | If true the Y-Axis Values will be multiplied with (-1) before charting.

Table 2: Layout settings for feature connections.


Connection configuration

Last edited: 10/5/2017 11:51:12 AM

Each connection of a feature to a pin has its own settings. The settings listed in table one are directly applied to the time series, the settings in table 2 are evaluated in a specific

Setting | Description
Drawing style | Defines how time series are charted. You can choose form a list of predefined options
Hie from legend | Can be used to hide specific time series from the legend.
Invert values | If true the Y-Axis Values will be multiplied with (-1) before charting.

Table 1: Settings for a feature connection

For each connection you can define layout settings that will apply to the time series resulting from this connection. These settings are only respected if the global chart setting time series coloring defines so.

If layout settings are defined directly on a connection they will overwrite the settings defined on the pin. If the layout settings are not defined on the pin and also not defined on the connection the system will try to get the layout settings from the display settings associated with the charted property. If the system cannot find any defined layout setting it will choose default values.

Setting | Description
Color | Defines the color of the time series
Line style | Defines the line style for the time series.
Line thickness | Defines the line thickness of the time series.
Symbol | Defines the symbol used to depicture data points
Symbol size | Defines the size of the symbol

Table 2: Layout settings for feature connections.


Value over axis

Last edited: 10/5/2017 11:51:22 AM

The chart type Value over axis shows the values of properties in an observation property structures over its position relative to a specified axis reference system.

The chart can picture observation data from any number of features of any type as long as the observation property structure contains a numeric or quantity property on its topmost level.

If the feature type does not support spatial data for observation the feature will not be drawn.

If the spatial system of a connected feature is not axis or if the spatial system of a connected feature is Axis but the feature uses another axis or another axis reference system the spatial data will be converted automatically. Note that conversion is not possible under all circumstances. If it is not possible the data will not be shown.


Chart configuration

Last edited: 10/5/2017 11:51:46 AM

The global settings that affect the layout of the chart as a whole. These settings do not influence what is drawn but just how things are drawn. Following tables describe the settings

Setting | Description
Axis | The axis on which the data is shown
Axis reference system | An axis reference system defined on the axis specified above on which the data is shown.
Comparison axis reference system | An axis reference system defined on the axis specified above that is used as second X axis for additional information
Position | Select from ·Start offset ·End Offset ·Middle
Filter from | Only observations with a position (see above) that is within Filter from and filter to will be charted. From and to values for the filter are defined with reference to the used Axis reference system.
Filter to
Header | A single line of text printed as chart header above the chart
Sub Header | A single line of text printed directly beneath the header
Header line | A single line of text printed above the chart
Footer line | A single line of text printed below the chart
Show data filter | Defines if a textual representation of the data filter is displayed on the chart.
Date formatting | Manual | Automatic
Manual date format | Defines the format used for displaying data & time values. You can choose from a list of predefined formats. ·MM-DD ·MM-DD-HH ·DD HH;MM ·HH:MM:SS
Manual offset | If not set the date & time values shown on the chart are shown with the current date time offset of the Application Server's time zone. If set date & time values are shown with the specified offset. The offset is given in minutes.
Include erroneous observations | Defines if the chart will show observations marked as erroneous or not.
Series coloring | Defines how series are colored. You can choose from a predefined list of options ·Determine from feature connection ·Use color palette
Naming of time series | This setting defines how the name of a time series is displayed (e.g. in legend). You can choose from a predefined list of options. ·Feature type + feature + property ·Feature + property ·Property

Table 1: General settings for the chart type

Setting | Description
Grid Color | The color of the grid lines
Show horizontal grid lines | Defines if horizontal grid lines (parallel to X-Axis) are shown
Show vertical grid lines | Defines if vertical grid lines (parallel to Y-Axis) are shown

Table 2: Settings for the display of a data grid

The chart legend can be used to describe the time series presented in a chart. Several settings are available to define where and how the legend is displayed. Table 3 lists these settings.

Setting | Description
Show legend | Defines if a legend will be shown or not. The legend will contain entries for all time series Only time series that are not hidden will be shown
Legend location | Defines where the legend will be shown in the chart. Options are left, right, top or bottom. Note that the client displaying the chart might limit the number of legend entries.
Show units in legend | If true the units of the time series will be shown in the legend entries.

Table 3: Legend settings

The value over time chart type allows the definition of up to 10 sub-graphs. Each sub-graph can be configured separately. Table 1 shows the settings available for each sub-graph. Each sub-graph contains settings for the left and right Y axis of that sub-graph. These settings are described in Table 2

Setting name | Description
Name | Name of the sub-graph. This name will be shown on the Y axis of the sub-graph.
Height | Defines the height of the sub-graph. The height of the sub-graph in the rendered chart equals a percentage of the total chart height. This percentage is calculated by dividing the specified height value with the sum of all height values defined for sub-graphs that have associated pins.
Settings for left Y axis | See Table 5
Settings for right Y axis | See Table 5
Scaling for X axis | Automatic, Fixed using the from to filter

Table 4: Global chart settings available for each of the 10 sub-graphs

Setting name

Description

Logarithmic scaling

Name of the sub-graph. This name will be shown on the Y axis of the sub-graph.

Color

The relative height of the sub-graph in relation to the total height of the chart.

Scaling Method

Defines how the axis is scaled, i.e. the minimum and maximum value that is shown on the axis. You can choose from a list of predefined options:

Fixed: Uses the settings scaling minimum value and scaling maximum value to specify the scaling.

Min-Auto: Uses the setting scaling minimum value for the lower boundary of scaling. The upper boundary is automatically determined based on the time series that are bound to the axis..

Auto-Max: Uses the setting scaling maximum value for the upper boundary of scaling. The lower boundary is automatically determined based on the time series that are bound to the axis..

Minimum interval: Uses the settings scaling minimum value and scaling maximum value to specify the scaling. If however the time series contain data that is out of these bounds the scaling will be automatically adapted.

Scaling Min value

Defines the minimum value for scaling

Scaling Max value

Defines the maximum value for scaling

Table 5: Global chart settings available for configuring


Connection configuration

Each connection of a feature to a pin has its own settings. The settings listed in table one are directly applied to the time series, the settings in table 2 are evaluated in a specific

Setting | Description
Drawing style | Defines how time series are charted. You can choose form a list of predefined options
Hie from legend | Can be used to hide specific time series from the legend.
Invert values | If true the Y-Axis Values will be multiplied with (-1) before charting.

Table 1: Settings for a feature connection

For each connection you can define layout settings that will apply to the time series resulting from this connection. These settings are only respected if the global chart setting time series coloring defines so.

If layout settings are defined directly on a connection they will overwrite the settings defined on the pin. If the layout settings are not defined on the pin and also not defined on the connection the system will try to get the layout settings from the display settings associated with the charted property. If the system cannot find any defined layout setting it will choose default values.

Setting | Description
Color | Defines the color of the time series
Line style | Defines the line style for the time series.
Line thickness | Defines the line thickness of the time series.
Symbol | Defines the symbol used to depicture data points
Symbol size | Defines the size of the symbol

Table 2: Layout settings for feature connections.


Cross chart

Last edited: 10/5/2017 11:51:22 AM

The cross chart chart type shows the values of two ore three properties in an observation property structures in a Cartesian coordinate system i.e. the properties . The chart can picture observation data from any number of features of any type as long as the observation property structure contains at least two numeric or quantity properties on its topmost level.

When displaying quantity properties the chart assumes that the values of the shown property are all expressed in the same unit. The unit is derived from the first shown observation. If a feature contains data in different units you need to process the data first.

When displaying numeric properties the unit displayed in the chart is derived from the feature property settings for the property drawn.

This chart type allows any number of pins typed with different feature types, each pin can connect any number of features of the same feature type. Each feature connected to a pin is presented as separate series.


Chart Configuration

Last edited: 10/5/2017 11:51:12 AM

The global settings that affect the layout of the chart as a whole. These settings do not influence what is drawn but just how things are drawn. Following tables describe the settings

Setting | Description
Header | A single line of text printed as chart header above the chart
Sub Header | A single line of text printed directly beneath the header
Header line | A single line of text printed above the chart
Footer line | A single line of text printed below the chart
Show data filter | Defines if a textual representation of the data filter is displayed on the chart.
Include erroneous observations | Defines if the chart will show observations marked as erroneous or not.
Series coloring | Defines how time series are colored. You can choose from a predefined list of options ·Determine from feature connection ·Use color palette
Naming of series | This setting defines how the name of a time series is displayed (e.g. in legend). You can choose from a predefined list of options. ·Feature type + feature + property ·Feature + property ·Property
Dimension | 2D 3D
Ratio X | Default = null (Automatic) 1;n = X:Y
Ratio Y |
Ratio Z |

Table 1: General settings for the chart type

Setting | Description
Grid Color | The color of the grid lines
Show Y grid lines | Defines if horizontal grid lines (parallel to X-Axis) are shown
Show X grid lines | Defines if vertical grid lines (parallel to Y-Axis) are shown
Show Z grid lines | Defines if vertical grid lines (parallel to Y-Axis) are shown

Table 2: Settings for the display of a data grid

Each of the axes in the cross chart can be configured with the settings shown in table 3

Setting name

Description

Logarithmic scaling

Name of the sub-graph. This name will be shown on the Y axis of the sub-graph.

Color

The relative height of the sub-graph in relation to the total height of the chart.

Scaling Method

Defines how the axis is scaled, i.e. the minimum and maximum value that is shown on the axis. You can choose from a list of predefined options:

Fixed: Uses the settings scaling minimum value and scaling maximum value to specify the scaling.

Min-Auto: Uses the setting scaling minimum value for the lower boundary of scaling. The upper boundary is automatically determined based on the time series that are bound to the axis..

Auto-Max: Uses the setting scaling maximum value for the upper boundary of scaling. The lower boundary is automatically determined based on the time series that are bound to the axis..

Minimum interval: Uses the settings scaling minimum value and scaling maximum value to specify the scaling. If however the time series contain data that is out of these bounds the scaling will be automatically adapted.

Scaling Min value

Defines the minimum value for scaling

Scaling Max value

Defines the maximum value for scaling

Table 5: Scaling options available for each axis


Pin configuration

Last edited: 10/5/2017 11:51:30 AM

For each pin you can define layout settings that will apply to all time series resulting from features connected to that pin. These settings are only respected if the global chart setting time series coloring defines so.

If layout settings are defined directly on a connection they will overwrite the settings defined on the pin. If the layout settings are not defined on the pin and also not defined on the connection the system will try to get the layout settings from the display settings associated with the charted property. If the system cannot find any defined layout setting it will choose default values.

Setting | Description
Color | Defines the color of the time series
Line style | Defines the line style for the time series.
Line thickness | Defines the line thickness of the time series.
Symbol | Defines the symbol used to depicture data points
Symbol size | Defines the size of the symbol
Drawing style | Defines how time series are charted. You can choose form a list of predefined options
Hie from legend | Can be used to hide specific time series from the legend.
Invert values | If true the Y-Axis Values will be multiplied with (-1) before charting.

Table 2: Layout settings for feature connections.


Connection configuration

Last edited: 10/5/2017 11:51:12 AM

Each connection of a feature to a pin has its own settings. The settings listed in table one are directly applied to the time series, the settings in table 2 are evaluated in a specific

Setting | Description
Drawing style | Defines how time series are charted. You can choose form a list of predefined options Line Point Spline Area
Hide from legend | Can be used to hide specific time series from the legend.
Invert values | If true the Y-Axis Values will be multiplied with (-1) before charting.

Table 1: Settings for a feature connection

For each connection you can define layout settings that will apply to the time series resulting from this connection. These settings are only respected if the global chart setting time series coloring defines so.

If layout settings are defined directly on a connection they will overwrite the settings defined on the pin. If the layout settings are not defined on the pin and also not defined on the connection the system will try to get the layout settings from the display settings associated with the charted property. If the system cannot find any defined layout setting it will choose default values.

Setting | Description
Color | Defines the color of the time series
Line style | Defines the line style for the time series.
Line thickness | Defines the line thickness of the time series.
Symbol | Defines the symbol used to depicture data points
Symbol size | Defines the size of the symbol

Table 2: Layout settings for feature connections.


Polar chart

Last edited: 10/5/2017 11:51:30 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Inclinometer chart

Last edited: 10/5/2017 11:51:24 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Extensometer chart

Last edited: 10/5/2017 11:51:16 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Map view

Last edited: 10/5/2017 11:51:28 AM

The map view allows the map-like graphical presentation of features, observations and other spatially located elements. It visualizes data using the stored spatial data on an abstraction of the Earth's surface. The Map view is able to transform data from different spatial reference systems.


Map view definition

Last edited: 10/5/2017 11:51:28 AM

Before a map can be rendered the the map content and the map layout has to be defined. These elements make up the map view definition. Map view definitions can persisted as map view templates for later reuse.

The options for defining the layout and content of a map view can be logically structured into the sections described in table 1.

Definition | Description
Map configuration | A UConfiguration containing settings that affect the map view as a whole. These settings do not influence what is drawn but mainly how things are drawn.
Data filter | If the map view displays observations the data filter can limit the observations.
Layers | Layers define what data is shown on the map and how that data is visualized. Each layer is an instance of a predefined layer type. Each of these types defines its own UConfiguration with settings that allow you to fine tune what is shown and how things are visualized on this layer.

Table 1: Logical structure of a map view definition


Map view configuration

Last edited: 10/5/2017 11:51:28 AM

The Map View Configuration is a UConfiguration that affects the map view as a whole. Table 1 and table 2 lists all settings available in this UConfiguration.

General

Setting

Description

Coordinate system

Default: If the global setting Default coordinate system is set this coordinate system will be used as default, else the predefined WGS 84 / Pseudo-Mercator (EPSG 3857) coordinate system will be used

Defines the coordinate system used to display data. This can be a projected or a geographic coordinate system.

When executed the map view will transform all displayed data to this coordinate system.

WMS and WFS will deliver data in the coordinate system defined in the configuration of that layer. Redbex will not transform the data delivered by WMS and WFS. It is up to the user to ensure that the data delivered by the WMS is conforming to the coordinate system specified with this setting. If these systems do not match layer will be shown but the location of objects will be wrong.

Scale bar

Default: Bottom Left

Defines if a scale bar is shown and where that scale bar is shown on the map.

Minimum visible length

Default: 400

This value can be used to define the maximum zoom detail when automatic zooming is enabled. The value is a length in the unit of the used coordinate system.

When automatically zooming to the contents of layers the map view will zoom in no further than to a rectangle with this side length.

Map scale unit system

Default: Metric

Defines the unit system used in the scale bar.

Show annotation layer

Default: Yes

If set the annotation stored with the Map view are shown, else annotations are hidden

Table 1: Settings of the Map view configuration's general group

Annotation layer settings

Setting | Description
Label size | Default 8 Defines the size of the labels shown with annotation elements. Size is given in pixels
Label color | Defines the color used for the labels shown with annotation elements. If set to null the labels will be shown in a default color.
Foreground color | The Foreground color is used for the graphical annotation elements (points, lines, and the border of polygons). If set to null the labels will be shown in a default color.
Background color | The Background / Fill color used for graphical annotations. This color is used for the filling of polygons as well as for the filling of points (if point size is large)
Opacity | Defines the opacity of the fill color used in polygon annotations. This setting is a value between 1 and 255. 255 is opaque, 1 is (nearly) fully transparent
Line style | Defines the line style used with annotation elements i.e. the line style for line annotations and the border style for polygon annotations.
Line thickness | Defines the thickness used to show line annotations and the borders of polygon annotations
Point symbol | Defines the symbol used to visualize point annotations.
Point symbol size | Defines the size for point symbols. The unit of this value is pixels you can us a value between 1 and 128.

Table 1: Settings of the Map view configuration's annotation group


Layers

Last edited: 10/5/2017 11:51:28 AM

A map view definition can have one or more layers that define contents and layout of the map view. Each layer is of a specific layer type that defines what data can be shown in that layer and how that data is shown. Each layer type also comes with its own UConfiguration that allows the user to fine tune what data the layer presents and how that data is presented.

Within a map view definition layers have a sequence, the sequence defines the drawing sequence, and therefore the Z-Order (ordering of overlapping two-dimensional objects) of the drawn items. Each layer has a name that can be defined by the user.

Some layer types can connect features and/or views to a map view. I.e. layers of these types will render spatial data and other data of features or of the features' observations. Features can be connected to a map view directly, or indirectly by connecting container features or by connecting views. How connected views and container features are handled depends on whether the layer is typed i.e. allowing only features of a specific feature type to be connected, or the layer is untyped i.e. allowing features of any type.

Handling of connected views and features with untyped layers

·View: All member features of the view are used as data source

·Container feature: If the layer's 'Expand container features' option is set all contained features of the container are used as data source but not the container itself. If that option is not set the container feature itself is used.

·Non-Container features are of course used as data source directly

Handling of connected views and features with typed layers

·View: All member features of the view that match the layer's feature type are used

·Container feature: If the container feature's type matches the layers feature type the container feature is not expanded. If it does not match all member features that match the type are used as data source

·Non-Container features are used as data source if the type matches the layer's type


%Text%

Navigation: Application Server > Presentation > Map view > Map view definition >

Map Annotations

Last edited: 10/5/2017 11:51:28 AM

Users can add annotations to map views. Annotations are graphical and textual elements that are shown at specific locations of the map. The user will draw these elements directly on the map view and they are stored alongside the map view definition. Figure 1 shows an example of a map view with annotation.

Redbex supports point, line and polygon annotations, the layout of these annotations are defined in the Map view configuration.


%Text%

Navigation: Application Server > Presentation > Map view > Map view definition >

Map file sets

Last edited: 10/5/2017 11:51:28 AM

The Map View provides some layer types that can visualize geographic data that is read from files in specific formats (e.g. Shapefile or GeoTIFF files). To enable the display of such files in a Map View these files first have to be stored on the Application Server as so called Map File Sets. The name Map File Sets results from the fact that many commonly used formats for storing geographical data are actually formats that use more than one file. E.g. while the term "shapefile" is quite common, it is misleading since the format consists of a collection of files with a common file name prefix, stored in the same directory.

Map File Sets are stored in a Domain context i.e. with a link to a specific domain. Map File Sets are propagated down the Domain structure, i.e. a Map File Set defined in a Domain is available in any sub domains of that domain.

Creating and modifying Map File Sets in a domain requires the domain Permission Manage Map file sets (19). Using a map file set, i.e. to display the contents of a map file set in a Map View layer requires Read (0) permission on the domain the Map File Set belongs to.

The Application Server determines the Map File Set format by inspecting the files the user stores with that Map File Set. The Application Server will only store a Map File Set if the files provided by the user are valid for one of the supported format. The following chapters describe each of the supported formats and the validation rules applied by the Application Server.

Each Map File Set on the Application Serer must be associated with one of the available coordinate systems. The Application Server will interpret the data in the Map File set as being in that specific coordinate system. Coordinate System specifications that might be inside one of the source files of a Map File Set are not used by the Application Server.


%Text%

Navigation: Application Server > Presentation > Map view > Map view definition > Map file sets >

Shapefile

Last edited: 10/5/2017 11:51:28 AM

The shapefile format is a digital vector storage format for storing geometric location and associated attribute information. The shapefile format was introduced with Arc View GIS version 2 in the early 1990s. The shapefile format is supported by a wide range of software systems.

The term shapefile is quite common, but is misleading since the format consists of a collection of files with a common file name prefix, stored in the same directory. The three mandatory files have filename extensions .shp, .shx, and .dbf. The actual shapefile relates specifically to the .shp file, but alone is incomplete for distribution as the other supporting files are required.

When validating if a set of given files represent a shapefile the Application Server checks following rules

·The file stem (the name of the file without the extension) must be the same for all files.

·All mandatory files must be present

o.shp — shape format; the feature geometry itself

o.shx — shape index format; a positional index of the feature geometry to allow seeking forwards and backwards quickly

o.dbf — attribute format; columnar attributes for each shape, in dBase IV format

·Additionally to the mandatory files only files with following extensions are allowed (optional files). Note that the Application Server does not make use of the information stored in these files.

o.prj — projection format; the coordinate system and projection information, a plain text file describing the projection using well-known text format

o.sbn and .sbx — a spatial index of the features

o.fbn and .fbx — a spatial index of the features that are read-only

o.ain and .aih — an attribute index of the active fields in a table

o.ixs — a geocoding index for read-write datasets

o.mxs — a geocoding index for read-write datasets (ODB format)

o.atx — an attribute index for the .dbf file in the form of shapefile.columnname.atx (ArcGIS 8 and later)

o.shp.xml — geospatial metadata in XML format, such as ISO 19115 or other XML schema

o.cpg — used to specify the code page (only for .dbf) for identifying the character encoding to be used

o.qix — an alternative quadtree spatial index used by MapServer and GDAL/OGR software


%Text%

Navigation: Application Server > Presentation > Map view > Map view definition > Map file sets >

TIFF World File

Last edited: 10/5/2017 11:51:28 AM

GeoTIFF is a public domain metadata standard which allows georeferencing information to be embedded within a TIFF file. The potential additional information includes map projection, coordinate systems, ellipsoids, datums, and everything else necessary to establish the exact spatial reference for the file.

The simple alternative to the inlined TIFF geospatial metadata is the *.tfw World File sidecar file format which sits in the same folder as the regular TIFF file. This format provides only a subset of the functionality of the standard GeoTIFF. A world file is a plain text computer data file used to georeference raster map images. In contrast to the inlined GeoTIFF format World files do not specify a coordinate system, this information comes from the Map File Set itself.

There are free software tools that can be used to extract georeferencing information from standard GeoTIFF files to world files. For more information please visit https://trac.osgeo.org/geotiff/.

When validating if a set of given files represents a TIFF World File format the Application Server checks if exactly one file with extension .TIFF and exactly one file with the extension .TFW must be present, no other files are allowed in the Map File Set.


%Text%

Navigation: Application Server > Presentation > Map view > Map view definition > Map file sets >

CAD file

Last edited: 10/5/2017 11:51:28 AM

Redbex supports the display of two popular CAD file formats .DWG and .DXF. Since those CAD file might hold references to other files (e.g. bitmaps, other CAD files) the CAD Map File Set type may consist of a single DWG or DXF or might be a collection of files including exactly one dwg or dxf file.

When validating if a set of given files represents a TIFF World File format the Application Server checks if exactly one file with extension .TIFF and exactly one file with the extension .TFW must be present, no other files are allowed in the Map File Set.


Layer types

Last edited: 10/5/2017 11:51:28 AM

Layer types are predefined types of map view layers that can render specific data in specific ways. Each layer type comes with its own UConfiguration that allows you to specify properties specific to that layer. Table 1 lists the settings available for all types of layers.

Layer types can be roughly classified into two groups: raster layers and vector layers. Raster layers display raster images (bitmaps), they usually take longer to load and they usually provide bitmaps for the whole shown map area. This also implies that placing a raster above other layers will usually hide the contents of layers below (except if the raster layer supports image transparency).

Layers of type vector layer display data using points, lines, polygons, symbols, icons and text. These layers can more easily be stacked above each other and are usually also rendered faster.

Vector layers can be further classified into Feature data layers and Miscellaneous data layers, Table 2 and table 3 describe the settings available for any layers of this classes.

Setting | Description
Visibility options
Hide contents | Advices the client to not show the contents of this layer by default. Client might however allow the user to make this layer visible. I.e. the contents of this layer will still be processed on the serer and sent to the client.
Layer visible from | This option is only available if Hide contents is not set. This defines the zoom level from which this layer will be visible. If this setting is empty the layer will always be visible Zoom levels 1-20, where 1 = whole world and 20 is most detailed zoom level.
Layer visible to | This option is only available if Layer visible from is set. This defines the zoom level till which the layer is visible. If this setting is empty the layer will be visible till zoom level 20 Note if layer from and to are set to the same value the layer will be visible only in that zoom level.

Table 1: Configuration settings available for all types of layers

Feature data layers

Feature data layers are vector layers, that are used to display feature data and observation data in various ways. These layers can be connected to features or views in order to define the data source.

Some feature data layer types can display features of any type as long as they have spatial information that can be transformed to the map view's spatial system, other layer types display data of specific feature types only or force you to select a feature type on which they operate.

Table 2 shows the settings common to all layer types of class feature data layer.

Setting

Description

Hide contents

If selected the layer's contents will not be shown. However the layer's contents can still be used to define zoom extents.

Defines zoom extent

If selected the contents of this layer and all other layers with this flag set will be used to calculate the boundary for the initial zoom extent.

Report layer

Defines that the layer is used as a report layer. If the map view is used in a report that loops through features the features bound to this layer will be automatically exchanged.

Feature limit

The maximum number of features that will be drawn. Even if more features are connected, the map will never show more features than defined by this setting.

Displaying many features on a map view might take a long time for getting and rendering the data. This setting should avoid long rendering time if you accidentally connect a huge number of feature (e.g. by connecting a view)

Opacity

Defines the opacity of all elements drawn in a specific layer. Valid values range from 0 to 255, where 255 is fully opaque.

Table 2: Settings available in the Common group of the UConfiguration for Feature data layers.

Miscellaneous data layers

There are other vector layer types that visualize data apart from Features and observations. Table 3 shows the settings common to all layer types of this class.

Setting | Description
Defines zoom extents | If selected the contents of this layer and all other layers with this flag set will be used to calculate the boundary for zoom extents.
Hide contents | If selected the contents of the layer will not be shown. However the contents of the layer can still be used to define zoom extents.

Table 3: Settings available in the Miscellaneous group of the UConfiguration for Feature data layers.


Bing maps

Last edited: 10/5/2017 11:51:06 AM

This raster layer type layer type uses the Microsoft's Bing Maps API to download and display maps as raster images. It supports most visualization types known from Microsoft's Bing Maps Webpage.

By using this layer you therefore agree to the terms of use of this API that can be found on http://www.microsoft.com/maps/product/terms.html.

Microsoft's Bing Maps API provides maps only in one specific Projected System (WGS 84 / Pseudo-Mercator, EPSG: 3857). Therefore layers of these types will only be displayed in the map view if the Coordinate system setting in the map view settings is set to this specific coordinate system. (in Redbex the WGS 84 / Pseudo-Mercator, EPSG: 3857 system is one of the predefined projected systems installed with every Application Server Database).

The Bing Maps API can only be accessed with a Bing Maps Key which you have to define with the Global Setting Miscellaneous: Bing Maps key. Without this key you won't be able to see Bing Maps. Please refer to Microsoft's online documentation for more information on Bing Map Keys or contact support.

Setting | Description
Map type | Defines what kind of map will be shown. You can choose from possible map types below: ·Road ·Arial ·Arial with labels

Table 1: Settings in the UConfiguration of the Bing maps layer type


Google maps

Last edited: 10/5/2017 11:51:22 AM

This raster layer type layer type uses the Google's Static Maps API to download and display maps as raster images. It supports most visualization types known from the Google Maps webpage.

By using this layer you therefore agree to the terms of use of this API that can be found on https://developers.google.com/maps/terms.

Google's Static Maps Maps API provides maps only in one specific Projected System (WGS 84 / Pseudo-Mercator, EPSG: 3857). Therefore layers of these types will only be displayed in the map view if the Coordinate system setting in the map view settings is set to this specific coordinate system. (in Redbex the WGS 84 / Pseudo-Mercator, EPSG: 3857 system is one of the predefined projected systems installed with every Application Server Database).

The Google Static Maps API can be only accessed only with a Google API Key. You therefore have to provide a Google API Key in the Global setting Miscellaneous: Google Maps API key to see Google Maps. For pricing please refer to the Google API documentation.

Setting | Description
Map type | Defines what kind of map will be shown. You can choose from possible map types below: ·Road map ·Satellite ·Terrain ·Hybrid

Table 1: Settings in the UConfiguration of the Google maps layer type


Open street maps

Last edited: 10/5/2017 11:51:30 AM

This layer uses the OpenStreetMap API to download and display raster images.

OpenStreetMap is open data, licensed under the Open Data Commons Open Database License (ODbL). Copyright © OpenStreetMap contributors. See http://www.openstreetmap.org/copyright for details.

The OpenStreetMap API provides maps only in one specific Projected System (WGS 84 / Pseudo-Mercator, EPSG: 3857). Therefore layers of these types will only be displayed in the map view if the Coordinate system setting in the map view settings is set to this specific coordinate system. (in Redbex the WGS 84 / Pseudo-Mercator, EPSG: 3857 system is one of the predefined projected systems installed with every Application Server Database).


WMS

Last edited: 10/5/2017 11:51:46 AM

Web Map Service (WMS) is a standard protocol for serving geo-referenced map images over the Internet that are generated by a map server. The WMS layer is a raster layer that can show the map images generated by Map Servers compliant with WMS version 1.1.1 or 1.3.0.

The UConfiguration for this raster layer type you can define the parameters necessary to access the WMS and get the map images. The supported values for most settings are announced by the WMS. If you know the Server URI of the WMS you can easily get supported settings for that WMS by issuing a GetCapabilities request like http://gis.lebensministerium.at/wmsgw/dopmaxresfree/?VERSION=1.3.0&REQUEST=GetCapabilities&SERVICE=WMS . However Clients like the Smart Client usually do this for you and will present the possible setting for the configured WMS.

Table 1 lists the settings in the UConfiguration for this layer type. Besides this common settings you can define one or multiple layers to be retrieved from the WMS, table 2 shows the parameters you can set for each of these layers.

Setting | Description
Defines Zoom Extent | If set the raster images received from the WMS will add to the Zoom extent of the map.
WMS Settings | This Structured data setting of the UConfiguration defines all the details needed to query data from WMS. See table 2 for details.

Table 1: Settings in the UConfiguration of the WMS maps layer type

Setting

Description

WMS URL

Mandatory. The URL (address) where the WMS is hosted.

Examples:

·http://gis.lebensministerium.at/wmsgw/dopmaxresfree/

·http://mesonet.agron.iastate.edu/cgi-bin/wms/goes/west_vis.cgi?

WMS User name

Optional. If the WMS Server you connect to requires authentication specify your user name here.

WMS Password

Optional. If the WMS Server you connect to requires authentication specify your password here.

Coordinate reference system

Mandatory. Name of the coordinate system in which the data shall be delivered by the WMS. See below for a detailed discussion on Coordinate Reference Systems

The Coordinate Reference System setting corresponds to the CRS (WMS version 1.3.0) or SRS (previous WMS versions) parameter in a WMS GetMap request

Min X

Defines the bounding box for zoom extents.

Min Y

Defines the bounding box for zoom extents.

Max X

Defines the bounding box for zoom extents.

Max Y

Defines the bounding box for zoom extents.

Axis inverted

Defines if X and Y are inverted.

Extra parameters

Optional. Some servers might require or might support extra parameters for a GetMap Request. This setting allows you to specify those extra parameters.

Use <key>=<value> syntax to specify parameters. Multiple parameters must be separated by comma e.g.

key1=value1, key2=value2

Output format

Mandatory. The output format in which the WMS Server will return the images.

Corresponds to the WMS Request parameter FORMAT for GetMap requests.

Exception format

Optional. Upon receiving a request that is invalid according to the WMS standard, the WMS server will issue a service exception report. The service exception report is meant to describe to the client application or its human user the reason(s) that the request is invalid.

The exceptions setting indicates the format in which the client wishes to be notified of service exceptions that arise during the request for a map.

Corresponds to the WMS Request parameter EXCEPTIONS for GetMap requests.

Background color

Optional, default is white (RGB 255,255,255)

This setting specifies the color to be used as the background for no-data areas, if either Background transparency is set to false or the chosen output format does not support transparency.

The Background Transparency setting corresponds to the BGCOLOR parameter in a WMS GetMap request

Table 1: Common settings in the UConfiguration of the WMS layer.

Setting | Description
Layer | Mandatory. The name of the layer that shall be loaded from the WMS. The layer setting of all layers defined will be used to generate the LAYERS parameter for the WMS Request.
Style | Mandatory. The style in which the layer shall be loaded from the WMS. The style setting of all defined layers will be used to generate the STYLES parameter for the WMS Request.

Table 2: Settings available for each layer in a WMS layer

WMS Version

There are different versions of the WMS standard. Redbex supports Version 1.1.1 and Version 1.3.0. When trying to load maps from a WMS Redbex will try to use Version 1.3.0 but will fall back to version 1.1.1 if the Server does not support 1.3.0.

Coordinate Reference System

The Coordinate reference system setting states what coordinate reference system applies to the WMS requests, i.e. what coordinate reference system is used for defining the area for which maps shall be returned and what coordinate system the returned maps are in. The value of the Coordinate reference system setting must be one one of the values defined by the WMS-Server, i.e. the WMS defines which coordinate reference systems are available.

Since WMS servers do not provide full definitions of coordinate systems Redbex cannot transform (re-project) data from WMS server. It is up to the user to choose a coordinate reference system that matches the reference system of your Map View Template.


Axis

Last edited: 10/5/2017 11:51:04 AM

This vector layer type is used to visualize axes and optionally axis reference systems on a map view. Axes are shown as poly-lines. One layer draws exactly one axis. You cannot connect any features to this layer.

Setting | Description
Defines zoom extent | If selected the contents of this layer and all other layers with this flag set will be used to calculate the boundary for zoom extents.
Hide contents | If selected the layer's contents will not be shown. However the layer's contents can still be used to define zoom extents.
Opacity | Defines the opacity of the elements shown on this layer
Hide in legend | If set, the layer and its elements will not be shown in the map legend

Table 1: General settings for the layer type Axis

Setting | Description
Label visible from | Defines the lower boundary of the zoom level from which label of this layer will be shown. Value must be between 1 and 20 where 1 means zoomed out to world extent and 20 means zoomed in to the maximum.
Label visible from | Option only available if Label visible from option is set Defines the upper boundary of the zoom level to which label of this layer will be shown. Value must be between 1 and 20 where 1 means zoomed out to world extent and 20 means zoomed in to the maximum.

Table 2: Visibility settings for the layer type Axis

Setting

Description

Show axis

If set the actual geometry of the axis (a poly-line with all axis points a nodes) will be shown on the map view.

Mark axis start

If set the start of the axis will be marked with the symbol defined in the Appearance settings. Use this if you want to visualize the axis direction.

Simplification tolerance

The simplification tolerance that shall be applied to the axis before drawing (using the Douglas Peucker simplification algorithm). A higher value usually results in faster but less accurate visualization of the axis.

The unit of this value is the unit of measurement in the projected coordinate system on which the axis definition is based.

Axis label

Defines how the axis shall be labeled. Available options are

·None: The axis will not have a label

·Axis name: The name of the axis will be shown. The label will be placed near the middle of the axis.

·Text template: The axis will be labeled according to the provided text template

Axis label template

The text template to be used

Show axis reference system

If set the starting point an the direction of selected axis reference systems will be shown.

Reference system label

Defines if and how shown reference systems are labeled

Reference system label template

If reference system label is set to Text template this setting defines the used text template.

Show mapping template

If set the mapping template for the selected axis reference systems will be shown.

Show information layers

If set the information layers for axis mapping templates will also be shown.

Show chainage

If set chainage labels will be placed along the axis in regular intervals.

Chainage interval

The interval between 2 displayed chainage points (measured along the 3D axis)

Axis reference system 1-10

Defines the selected axis reference systems.

Table 4: Specific settings for the layer type Axis

Setting | Description
Label size | Defines the size of the label in pixels.
Label color | Defines the color of the axis label color
Foreground color | Defines the foreground color for the axis, i.e. the color in which the axis will be drawn.
Background color |
Line style | Defines the line style that is used for drawing the axis
Line Thickness | Defines the line thickness that is used for drawing the axis
Point symbol for axis | The point symbol used to
Point size | SIze to use for symbols. Given in pixels.

Table 5: Appearance settings for the layer type axis


Feature location

Last edited: 10/5/2017 11:51:16 AM

This vector layer type can be used to display the location of features (or one of each feature's observations) on a map. You can connect any number of features to layers of this type. The layer belongs to the layer type class Feature data untyped.

The layer type will show LSO of all connected features. Connected features that have no spatial support will not be shown on the map. For features that have spatial support on observations the location of one of the observations will be shown (by default the latest observation, see Observation date setting).

If the LSO of features connected to this thematic layer is given in another spatial system or another spatial reference system than the system used for the map view definition the LSO will be transformed and - if transformation is possible - displayed. See the chapter transformation of spatial data for more details.

If a feature is connected multiple times (e.g. through views) it will be displayed only once. Table 1 shows the settings available for this thematic layer

Setting

Description

Hide contents

If selected the layer's contents will not be shown. However the layer's contents can still be used to define zoom extents.

Defines zoom extents

If selected the contents of this layer and all other layers with this flag set will be used to calculate the boundary for zoom extents.

Report layer

Defines that the layer is used as a report layer. If the map view is used in a report that loops through features the features in this layer will be automatically exchanged.

Feature limit

The maximum number of features that will be drawn. Even if more features are connected, the map will never show more features than defined by this setting.

Displaying many features on a map view might take a long time for getting and rendering the data. This setting should avoid long rendering time if you accidentally connect a huge number of feature (e.g. by connecting a view)

Expand container features

If this option is set bound container features are expanded and the contents of the container feature are shown.

LSO display

The location of a feature (or the observation) can be displayed on the map either as point or as the original geometry. If displayed as point and if the original geometry of the displayed feature or observation is not a point the geometry will be converted to a point geometry (for details on this conversion see below)

Feature label

Defines if a label is added to drawn features and what text is shown with the label. You can choose from a predefined list of formats:

·None

·Feature name

·Feature type + feature name

Show elevation

Defines if the elevation of each feature is added to the feature label.

Observation status

A date & time value that will be used to pick the observation that defines the feature location if the features spatial support is on observations.

The actual location shown will be the location of the observation that is nearest to this specified date & time.

If not given the system will use the latest observation available.

Table 1: Settings for the thematic layer Feature location

Table 2 shows visualization settings that influence how features are displayed. If these settings are not given the system will try to get visualization settings from the Feature type, if it cannot get it from there the system will choose default settings

Setting

Description

Label color

Defines the color of the label text

Label size

Defines the size of labels. Given in points (pt). Note that labels are not resized if the map is zoomed.

Foreground color

Defines the color for the graphical elements used to display the feature's geometry and data.

Background color

Defines the color that is used to fill polygon geometries.

Line style

Defines the line style that is used to draw line and polygon geometries

Line thickness

Defines the thickness of lines used to display features

Point display type

Defines how objects are displayed.

Symbol: objects will be shown with the selected point symbol

Bitmap: objects will be shown with the selected bitmap

Feature type icon: objects will be shown with the feature type icon

Symbol & bitmap: objects will be shown with the selected point symbol plus the selected bitmap. The bitmap is placed with a small offset

Symbol & feature type icon: objects will be shown with the selected point symbol plus the feature type icon. The icon is placed with a small offset

Point symbol

Defines the symbol used for point geometries, the same symbol is also used if line or polygon geometries are shown as point

Feature type icon size

The size of the feature type icon if the point display type is set to Feature type icon or Symbol and feature type icon.

Point symbol size

The size used for point symbols. The size is given in pixels.

Symbol image

The image used if point display type is set to Bitmap or Symbol & Bitmap. Allows the selection of a PNG image. We suggest to use only small images with transparent background.

Table 2: Appearance settings for the Feature location layer type

Midpoint calculation

When the Map view shows the location of an element as Midpoint that midpoint is calculated differently for different types of geometries and differently for projected and geographic coordinate systems, see tables 1 and 2 for detail.

Geometry | Midpoint calculation
Point | Midpoint is same as point
Multi point | Midpoint is Centroid of the Convex hull if the convex hull is a polygon. Midpoint is Centroid of envelope if convex hull is a line.
Line | Midpoint is Centroid of the Convex hull if the convex hull is a polygon. Midpoint is Centroid of envelope if convex hull is a line.
Multi-line | Midpoint is Centroid of the Convex hull if the convex hull is a polygon. Midpoint is Centroid of envelope if convex hull is a line.
Polygon | Midpoint is Centroid of Polygon
Multi-Polygon | Midpoint is Centroid of Convex hull of Multi Polygon

Table 1: Definition of Midpoint for different types of geometries on a projected coordinate system

The convex hull of a geometry defined on a projected coordinate system is the smallest convex geometry that completely encompasses all the points in a given instance. A convex geometry is one in which no interior angle is greater than 180 degrees, so that the sides do not ever bend inwards or contain indentations.

The envelope of a geometry represents the smallest axis-aligned rectangle that completely encompasses every part of the geometry.

Geometry | Midpoint calculation
Point | Midpoint is same as point
Multi point | Envelope center
Line | Envelope center
Multi-line | Envelope center
Polygon | Envelope center
Multi-Polygon | Envelope center

Table 2: Definition of Midpoint for different types of geometries on a geographic coordinate system

The Envelope center is the average position of all vectors that describe the location of each point in the geometry from the center of the earth. This is a very simple approximation of the center point of any type of geometry based on a geographic coordinate system.


Observation location

Last edited: 10/5/2017 11:51:30 AM

This vector layer displays the location of the observations of features, optionally observations of each feature can be connected by a line forming an observation track.

This layer type can bind any number of features. Location of all observations of all connected features and of all observations of all features in all connected views will be shown. If a feature is connected multiple times (e.g. through views) it will be displayed only once.

Connected features that have no spatial support, no spatial system set or missing LSO will not be shown on the map.

This layer type will use the data filter of the map view definition to filter the observations shown on the map.

Setting

Description

Defines zoom extents

If selected the contents of this layer and all other layers with this flag set will be used to calculate the boundary for zoom extents.

Hide contents

If selected the layer's contents will not be shown. However the layer's contents can still be used to define zoom extents.

Report layer

Defines that the layer is used as a report layer. If the map view is used in a report that loops through features the features in this layer will be automatically exchanged.

Feature limit

The maximum number of features that will be drawn. Even if more features are connected, the map will never show more features than defined by this setting.

Displaying many features on a map view might take a long time for getting and rendering the data. This setting should avoid long rendering time if you accidentally connect a huge number of feature (e.g. by connecting a view)

Opacity

A value between 1 and 255 that defines the opacity of the visual elements shown in this layer. 1 = nearly transparent, 255 is opaque.

Expand container features

If this option is set bound container features are expanded and the contents of the container feature are shown.

Max. observations per feature

Defines an upper limit of observations shown for each feature. If a feature has more observations than this number only the first observations will be shown.

LSO display

The location of a feature (or the observation) can be displayed on the map either as point or as the original geometry. If displayed as point and if the original geometry of the displayed feature or observation is not a point the geometry will be converted to a point geometry (for details on this conversion see below)

Feature label

Defines if a label is added to drawn features and what text is shown with the label. You can choose from a predefined list of formats:

·None

·Feature name

·Feature type + feature name

Connect observations

If true the observations of each feature will be connected by a line. The connections will be shown from one observation to is successor (time wise)

Observation label

Defines the label shown for each observation

Date format

Date & time format string for displayed date and time values

Table 1: Settings for the layer type Observations

Table 2 shows visualization settings that influence how features are displayed. If these settings are not given the system will try to get visualization settings from the Feature type, if it cannot get it from there the system will choose default settings

Setting

Description

Label color

Defines the color of the label text

Label size

Defines the size of labels. Given in points (pt). Note that labels are not resized if the map is zoomed.

Foreground color

Defines the color for the graphical elements used to display the feature's geometry and data.

Background color

Defines the color that is used to fill polygon geometries.

Line style

Defines the line style that is used to draw line and polygon geometries

Line thickness

Defines the thickness of lines used to display features

Point display type

Defines how objects are displayed.

Symbol: objects will be shown with the selected point symbol

Bitmap: objects will be shown with the selected bitmap

Feature type icon: objects will be shown with the feature type icon

Symbol & bitmap: objects will be shown with the selected point symbol plus the selected bitmap. The bitmap is placed with a small offset

Symbol & feature type icon: objects will be shown with the selected point symbol plus the feature type icon. The icon is placed with a small offset

Point symbol

Defines the symbol used for point geometries, the same symbol is also used if line or polygon geometries are shown as point

Feature type icon size

The size of the feature type icon if the point display type is set to Feature type icon or Symbol and feature type icon.

Point symbol size

The size used for point symbols. The size is given in pixels.

Symbol image

The image used if point display type is set to Bitmap or Symbol & Bitmap. Allows the selection of a PNG image. We suggest to use only small images with transparent background.

Table 2: Appearance settings for the layer type observation location

Midpoint calculation

When the Map view shows the location of an element as Midpoint that midpoint is calculated differently for different types of geometries and differently for projected and geographic coordinate systems, see tables 1 and 2 for detail.

Geometry | Midpoint calculation
Point | Midpoint is same as point
Multi point | Midpoint is Centroid of the Convex hull if the convex hull is a polygon. Midpoint is Centroid of envelope if convex hull is a line.
Line | Midpoint is Centroid of the Convex hull if the convex hull is a polygon. Midpoint is Centroid of envelope if convex hull is a line.
Multi-line | Midpoint is Centroid of the Convex hull if the convex hull is a polygon. Midpoint is Centroid of envelope if convex hull is a line.
Polygon | Midpoint is Centroid of Polygon
Multi-Polygon | Midpoint is Centroid of Convex hull of Multi Polygon

Table 1: Definition of Midpoint for different types of geometries on a projected coordinate system

The convex hull of a geometry defined on a projected coordinate system is the smallest convex geometry that completely encompasses all the points in a given instance. A convex geometry is one in which no interior angle is greater than 180 degrees, so that the sides do not ever bend inwards or contain indentations.

The envelope of a geometry represents the smallest axis-aligned rectangle that completely encompasses every part of the geometry.

Geometry | Midpoint calculation
Point | Midpoint is same as point
Multi point | Envelope center
Line | Envelope center
Multi-line | Envelope center
Polygon | Envelope center
Multi-Polygon | Envelope center

Table 2: Definition of Midpoint for different types of geometries on a geographic coordinate system

The Envelope center is the average position of all vectors that describe the location of each point in the geometry from the center of the earth. This is a very simple approximation of the center point of any type of geometry based on a geographic coordinate system.


Observation property - Midpoint

Last edited: 10/5/2017 11:51:30 AM

This vector layer displays values of selected observation property of features at the feature or observation location. The location of the shown geometry depends on the spatial data support of the feature type. The displayed observations are always shown as point (midpoint of the actual geometry). The layer can be configured in a way that color and/or size of the displayed point is chosen automatically based on the value of the observation property.

This layer type can bind any number of features, it will use the data filter of the map view definition to filter the observations shown on the map. The layer also supports aggregation to display observation properties out of level-1 collections.

Figure 1: Example of a map view using an Observation property - Midpoint layer

Transforming observation values into point sizes and colors

Setting

Description

Expand container features

If this option is set bound container features are expanded and the contents of the container feature are shown (instead of the bound feature)

Max. observations per feature

Defines an upper limit of observations shown for each feature. If a feature has more observations than this number only the first observations will be shown.

Transversal offset

Transversal offset is an offset value to be applied to features or observations located with axis.

Feature Type

Fixes and limits the feature type for the layer. Once set only features of that feature type can be bound to the layer

Observation property

When the feature type is fixed, this displays the possible available properties that will be used as observation property value.

Note: this configuration appears when a feature type is selected.

Collection aggregation

Defines how collection properties are handled. Default is First value. Options are:

·First value

·Last value

·Sum

·Average

·Minimum value

·Maximum value

Note: this configuration appears when a feature type is selected.

Aggregation classification filter

If set only those properties will be used. For collection properties this sets a filter: only those properties inside a collection shall be used, where a value of another classification property inside this collection equals given value.

Note: this configuration appears when a feature type is selected.

Observation status

A point of time for observations to get the closest observations from the supplied date time. When set system will try to get the nearest observation to that point of time. Default is null. If null system retrieves the latest observation.

Scaled point display type

Allows user to select the display type. Options are

·Scaled point

·Scaled point with color ramp

Scaled point: Scaled point is the simplest presentation of the data, which based on the negative and positive color selected, draws the geometry based on whether the values are positive and negative.

Scaled point with color ramp: Uses a superior logic to compute the the color from a color ramp using the value, positive and negative color and expected value ranges(min and max).

Use logarithmic scaling

Default is false. When set to true both the color and size of the geometries are computed using uses logarithmic scaling.

Minimum expected value

Minimum expected value, minimum expected value allows user to define the minimum expected value of the selected property. This value is used for computing the the geometry size and color.

Default: -1000

Maximum expected value

Maximum expected value, maximum expected value allows user to define the maximum expected value of the selected property. This value is used for computing the the geometry size and color. Default: 1000

Minimum point size

Minimum point size, used for computing thickness for geometries, used to compute the thickness of the geometry using the observation property value.

Maximum point size

Maximum point size, used for computing thickness for geometries, used to compute the thickness of the geometry using the observation property value.

Negative value color

Negative value color, the color to use when the values are negative or in the bottom range of the minimum expected value.

Note: How colors are computed depend on the setting "Scaled point display type" above

Positive value color

Positive value color, the color to use when the values are positive or in the upper range of the maximum expected value.

Note: How colors are computed depend on the setting "Scaled point display type" above

Decimal places

Decimal places to display when showing numeric values as text display.

Feature name display

Allows user to select how and what information of the features or observation value shall be shown along with the geometry. User has the following options:

·None: Shows no label, only geometries

·Property value: Shows the value of the selected property using the "Decimal places" setting.

·Text template: Allows user to take advantage of the text templates to customize the labels according to theirs needs.

Table 1: Available configuration settings for this layer type


Observation property - Shape

Last edited: 10/5/2017 11:51:30 AM

This vector layer displays a selected observation property values of features in the feature or observation location. The location of the shown geometry depends on the spatial data setting of the feature or observation location. The geometries are always shown as defined in the feature or observation spatial data(Point, Line, Polygon).

This layer type can bind any number of features. This layer type will use the data filter of the map view definition to filter the observations shown on the map. The layer also allows to use basic set aggregation functions to be used for observation property collection which are described below.

The layer allows to easily visualize an observation property values on a map, an example could be seen in the following example which illustrates the observation property value e.g. X of one feature. With additional settings the property values are used to compute the color and the size of geometry and drawn in the corresponding location.

Setting

Description

Defines zoom extents

If selected the contents of this layer and all other layers with this flag set will be used to calculate the boundary for zoom extents.

Hide contents

If selected the layer's contents will not be shown. However the layer's contents can still be used to define zoom extents.

Report layer

Defines that the layer is used as a report layer. If the map view is used in a report that loops through features the features in this layer will be automatically exchanged.

Feature limit

The maximum number of features that will be drawn. Even if more features are connected, the map will never show more features than defined by this setting.

Displaying many features on a map view might take a long time for getting and rendering the data. This setting should avoid long rendering time if you accidentally connect a huge number of feature (e.g. by connecting a view)

Opacity

A value between 1 and 255 that defines the opacity of the visual elements shown in this layer. 1 = nearly transparent, 255 is opaque.

Expand container features

If this option is set bound container features are expanded and the contents of the container feature are shown.

Max. observations per feature

Defines an upper limit of observations shown for each feature. If a feature has more observations than this number only the first observations will be shown.

Transversal offset

Transversal offset is an offset value to be applied to features or observations located with axis.

Feature Type

Fixes and limits the feature type for the layer. Once set only features of that feature type can be bound to the layer

Observation property

When the feature type is fixed, this displays the possible available properties that will be used as observation property value.

Note: this configuration appears when a feature type is selected.

Collection aggregation

Defines how collection properties are handled. Default is First value. Options are:

·First value

·Last value

·Sum

·Average

·Minimum value

·Maximum value

Note: this configuration appears when a feature type is selected.

Aggregation classification filter

If set only those properties will be used. For collection properties this sets a filter: only those properties inside a collection shall be used, where a value of another classification property inside this collection equals given value.

Note: this configuration appears when a feature type is selected.

Observation status

A point of time for observations to get the closest observations from the supplied date time. When set system will try to get the nearest observation to that point of time. Default is null. If null system retrieves the latest observation.

Use logarithmic scaling

Default is false. When set to true both the color and size of the geometries are computed using uses logarithmic scaling.

Minimum expected value

Minimum expected value, minimum expected value allows user to define the minimum expected value of the selected property. This value is used for computing the the geometry size and color.

Default: -1000

Maximum expected value

Maximum expected value, maximum expected value allows user to define the maximum expected value of the selected property. This value is used for computing the the geometry size and color. Default: 1000

Minimum outline thickness

Minimum outline thickness for geometries, used to compute the thickness of the geometry using the observation property value.

Maximum outline thickness

Maximum outline thickness for geometries, used to compute the thickness of the geometry using the observation property value.

Minimum value color

Minimum value color, the color to use when the values are in the bottom range of the minimum expected value.

Note: How colors are computed depend on the setting "Scaled point display type" above

Maximum value color

Maximum value color, the color to use when the values are in the upper range of the maximum expected value.

Note: How colors are computed depend on the setting "Scaled point display type" above

Decimal places

Decimal places to display when showing numeric values as text display.

Feature name display

Allows user to select how and what information of the features or observation value shall be shown along with the geometry. User has the following options:

·None: Shows no label, only geometries

·Property value: Shows the value of the selected property using the "Decimal places" setting.

·Text template: Allows user to take advantage of the text templates to customize the labels according to theirs needs.


%Text%

Navigation: Application Server > Presentation > Map view >

To-scale map view PDF

Last edited: 10/5/2017 11:51:44 AM

The Application Server supports generating documents from Map View Definitions that are in a user defined scale (e.g. 1:10000). These to-scale map view documents are generated as bitmap files which are embedded in PDF documents and can therefore be easily printed using that exact scale.

The generation of these to-scale PDFs is done as a job and the resulting PDF will be available in the output files after the job has finished.

Limitations

When creating to scale raster files and PDF files several limitations apply.

Maximum pixel size of the embedded raster file: Rendering PNG files needs memory on the Application Server. To limit the load on the Application Server there is a fixed limit for the size of the raster file of 10000 x 10000 pixels.

Maximum size of PDF document

DPI and pixel size

When generating a to-scale map view you can specify the scale e.g. 1:10000, that defines how many real-world units are represented by one unit on paper. Therefore the scale setting defines the paper size of the to-scale PDF. The DPI of raster image embedded in the PDF can also be defined and has great influence on the shown details especially when using raster background layers. Higher DPI produce higher quality to-scale maps, however the higher the DPI the bigger the size of the embedded bitmap.

Assuming a map is generated with meters as base unit following formula applies

PaperWidth = RealWorldWidthOfMap * Scale

ImageWidth = PaperWidth * 39.37 * DpiSetting

Examples:

·If map shows a total width of 10000 meters and scale factor is 1:10000 the paper width will be 1m. If DPI is set to 70 the size of the embedded bitmap will be ~2756 px

·If map shows a total width of 10000 meters and scale factor is 1:10000 the paper width will be 1m. If DPI is set to 300 the size of the embedded bitmap would be ~11811 px which would exceed the limits (see above)


Axis section drawing

Last edited: 10/5/2017 11:51:04 AM

Axis section drawings display data along a chosen axis reference system. Axis section drawings are generated in a specific scale i.e. the distance of drawing elements in the row content of the drawing is corresponding to the real-world position of features or observations along the axis reference system.

Redbex renders axis section drawings in DXF (Drawing Interchange Format) in version 2013.

Anatomy of an axis section drawing

An axis section drawing is structured in a drawing header, rows and a drawing footer. Rows consist of a row header, a row legend and the row content. Figure 1 shows this basic structure of an axis section drawing.

Figure 1: Anatomy of an axis section drawing


Axis section drawing definition

Last edited: 10/5/2017 11:51:04 AM

Axis section drawings are generated based on an axis section drawing definitions. These definitions contain settings for layout and content of the axis drawing; they can be persisted as axis section drawing templates.

Wherever the definition of an axis section drawing contains linear distances those distances have to be given in millimeters.

The options available for a axis section drawing definition can be logically structured into the sections described in table 1.

Definition | Description
Axis reference system & interval | The definition of the axis reference system and an interval in this reference systems for which the axis section drawing is created.
Global settings | Settings that affect the section drawing as a whole. These settings do not influence what is drawn but just how things are drawn.
Observation filter | Defines which observation data will be drawn by defining an observation filter.
Row settings | Each row has its own UConfiguration that defines what and how things in this row are rendered. The UConfiguration contains common settings available for each row type as well as settings specific for a row type.
Binging settings | For each element (feature or view) bound to an axis section drawing row some general settings that define the visual appearance can be made.

Table 1: Logical structure of settings available in the definition of a axis section drawing


Axis reference system & filter

Last edited: 10/5/2017 11:51:06 AM

An axis section drawing definition must always include the definition of an axis reference system. All data presented in the axis section drawing will be presented in that selected reference system. I.e. if the definition includes data from features or observations using other spatial reference systems the spatial information will be transformed to the selected axis reference system (if possible).

Additionally the user can define an interval on that reference system to limit the amount of data rendered in the axis section drawing. This interval can be defined using a static or a dynamic axis interval. No matter which features or views are bound to the drawing definition only elements that are located within this interval (possibly after a spatial transformation) will be drawn.

A static axis interval is simply defined by providing two offsets in the axis reference system of the drawing.

A dynamic interval is specified by referencing a feature of type Axis position, specifying a timestamp and specifying two offsets. The basic location reference is the axis location recorded for the selected axis position feature that nearest to the passed timestamp. If no timestamp is given, the latest observation is used. From this basic location reference the interval is calculated by adding offset 1 and offset 2. Table 1 gives some examples of this dynamic interval logic.

Location | Offset 1 | Offset 2 | Resulting axis interval
200 | -100 | 0 | 100 to 200
200 | 0 | 100 | 200 to 300
200 | -100 | -200 | Empty interval

Table 1: Examples for settings of a dynamic axis interval.


Observation filter

Last edited: 10/5/2017 11:51:04 AM

The observation filter for an axis section drawing definition is a regular observation filter can be used to filter the observations shown on the axis section drawing.


Global settings

Last edited: 10/19/2017 5:04:10 AM

Axis section drawing settings is a UConfiguration that includes settings which affect the section drawing as a whole. These settings do not influence what is drawn but just how things are drawn. Tables 1 and 2 list the available settings.

General settings

Setting

Description

Scaling factor

The factor that is used to map real-world axis reference system offsets to millimeters. See below for more details

Default: 1.0

Validation: > 0.1 and ≤ 10 000

See below for examples for this setting.

Title

A text template used as used to define a title that will be shown on top of the drawing.

The text template may includes specific variables to express properties of the used axis reference system and the underlying axis.

Subtitle 1

A text template used as used to define the first subtitle that will be shown beneath the title. This string is a text template.

The text template may includes specific variables to express properties of the used axis reference system and the underlying axis.

Subtitle 2

A text template used as used to define second subtitle that will be shown beneath the title. This string is a text template.

The text template may includes specific variables to express properties of the used axis reference system and the underlying axis.

Footer

A text template used to define a footer line that will be shown beneath the drawing. This string is a text template.

The text template may includes specific variables to express properties of the used axis reference system and the underlying axis.

Drawing header height

Height of the drawing header in mm.

Title font size

Size of the font used for the title. Given in millimeters.

Default: 10

Validation: > 0.1 and ≤ 100

Subtitle font size

Size of the font used for subtitle 1 and subtitle 2. Given in millimeters.

Default: 6

Validation: > 0.1 and ≤ 100

Header / footer font size

Size of the font used for header and footer text. Given in millimeters.

Default: 3

Validation: > 0.1 and ≤ 100

Header / footer color

Defines the color for the text shown in the drawing header and footer.

Default: Black

Row header width

Width of the row header in millimeter. You can hide the row header by setting this to zero.

Default: 40

Validation: ≥ 0.0

Legend width

Width of the row legend in millimeter. You can hide the row legend by setting this to zero.

Default: 30

Validation: ≥ 0.0

Row title font size

Defines the size in millimeters of the font used for showing row headers.

Default: 2.5mm

Validation: ≥ 0.1

Row subtitle font size

Defines the size in millimeters of the font used for showing row sub- headers.

Default: 2mm

Validation: ≥ 0.1

Row border stroke color

Defines the color used to draw of the row borders

Default: Dark grey

Row border stroke width

The width in millimeters of the row row border strokes.

Default: 0.5

Validation: > 0.1 and ≤ 1.0

Table 1: General Axis section drawing settings

Scaling factor examples

The scaling factor defines how 'real world' units i.e. the linear units used with the axis reference system are mapped to millimeters. The millimeters used to represent a distance given in the used axis reference system is calculated by multiplying the given distance with the scaling factor. Table 3 shows some examples.

Real world value | Scaling factor | Size on drawing
1 meter | 1 | 1 mm
100 meters | 0.1 | 10 mm
100 meters | 0.5 | 50
1 mile | 304.8 | 304.8 mm (=1 foot)
1 mile | 25.4 | 25.4 mm (=1 inch)

Table 2: Examples of scaling factors

Vertical grid settings

The vertical grid settings define the display of vertical grid lines and ticks. While the definition of this vertical grid is global it can be overridden on a per-row basis.

Setting

Description

Color

Sets the default color of the graphical elements that are used for the vertical grid. This setting can be overridden in every row.

Default: Light grey

Major ticks distance

Defines the default distance between two consecutive major ticks; given in the linear unit of the used axis reference system. This setting can be overridden in every row.

Default: 10

Validation: > 0.0

Minor ticks between major ticks

Defines how many minor ticks shall be shown between two major ticks. If set to zero no minor ticks will be shown. This setting can be overridden in every row.

Default: 9

Validation: ≥ 0

Grid style

Defines the style of the grid display. Following options are available

·Style 1: Major ticks are lines from top of row to bottom, minor ticks are short lines starting at the row bottom

·Style 2: Major ticks are lines from top of row to bottom, minor ticks are short lines starting at the row bottom and a mirrored short line starting from the row top

Grid Z-Order

Specifies if the grid lines are drawn in front of other drawing elements or in the back of other drawing elements.

Table 3: Axis section drawing settings for the vertical grid

Other settings

Setting | Description
Status date | When displaying the location of feature with spatial support on observations the location of the feature will be set according to the location stored with the observation nearest to the given date and time value. If null the latest observation's spatial data will be used. Default: null

Table 3: Axis section drawing settings in the Other settings group


Row settings

Last edited: 10/19/2017 5:45:24 AM

Each row in an axis section drawing is of a specific row type. Redbex pre-defines the available row-types. Each row type has its own UConfiguration that allows the user to specify settings that influence how a specific instance of that row type will be rendered.

Table 1 describes the UConfiguration settings common to all row types.

Setting | Description
Hidden | If set this row will not be rendered. This setting might be useful while designing your axis section drawing definition to temporarily disable rendering of specific rows.
Height | Height of the row given in mm. Default: 20mm Validation > 0.1
Header | The title of the row shown in the row header
Sub-header | Subtitle of the row shown in the row header
Row Header drawing | A raster image that will be shown in beneath the reader and sub-header. The raster file will be scaled to fit into the area of the header. Note that the size of the raster file must be < 24 KiB
Header font color | Defines the color used for the row header and sub-header. Default: Black
Header font bold | Defines if the row header shall be shown in bold face. Default: false
Background color | Defines the background color for the row. The background color will be used in the row header, row legend and in the row content.
Data font color | Defines the color for text shown in the content area of a row.
Data font size | Size of the font used for texts in the content area of a row. Given in millimeters. Default: 2 Validation: > 0.1 and ≤ 100
Number format | Defines how numeric values are displayed. Any valid Number formatting string can be used.
Show row legend | If set the row will render a legend into the legend area.

Table 1: Common settings for all rows

Each row can define its own vertical grid. If so the definition of the vertical grid will override the global definition of the vertical grid for this row. Table 2 shows the available settings for the vertical grid.

Setting

Description

Show vertical grid

Defines if a vertical grid is displayed for this row.

Default: false

Color

Sets the color of the graphical elements that are used for the vertical grid. If not set (null) the default color of the axis section drawing settings will be used.

Default: null

Major ticks distance

The distance between two consecutive major ticks; given in the linear unit of the used axis reference system. If not set (null) the default color of the axis section drawing settings will be used.

Default: null

Validation: > 0.0

Minor ticks between major ticks

Defines how many minor ticks shall be shown between two major ticks. If not set (null) the default color of the axis section drawing settings will be used.

Default: 9

Validation: ≥ 0.0

Grid style

Defines the style of the grid display. If not set (null) the default color of the axis section drawing settings will be used.

Following options are available

·Style 1: Major ticks are lines from top of row to bottom, minor ticks are short lines starting at the row bottom

·Style 2: Major ticks are lines from top of row to bottom, minor ticks are short lines starting at the row bottom and a mirrored short line starting from the row top

Gird Z-Order

Defines if the Grid (vertical and horizontal) is shown behind or in front of other elements in this row.

Options are

·In Back

·In Front

Default:In Back

Table 2: Axis section drawing settings for the vertical grid


Binding settings

Last edited: 10/19/2017 5:04:44 AM

For each object (feature or view) that is bound to a row in the definition of an axis section drawing settings for visual appearance can be defined. All those settings have null as default. It depends on the row type if and how these settings are used.

Setting | Description
Fore color |
Back color |
Line type |
Line width | Given in mm Validation: ≥ 0.1 and < 5
Symbol predefined | Selection of predefined symbols
Symbol custom | Custom png symbol to be used
Symbol size | mm

Table 1: Settings for each binding


Row types

Last edited: 10/19/2017 5:04:54 AM

In the following you find a detailed description of all row types available.


Axis property

Last edited: 10/5/2017 11:51:04 AM

Displays specific properties of the axis on which the drawing's reference system is defined in regular intervals.

Characteristic |
Typing | This row type does not display feature or observation data
Binding | This row type does not display feature or observation data
Handling of container features | This row type does not display feature or observation data

Table 1: Characteristics of this row type

Setting | Description
Interval | The interval between two shown entries. This interval is given in the linear unit used by the axis reference system.
Property | The property to be displayed. Options are: ·Bearing: Shows the bearing of the axis (in compass degrees) ·Inclination: Shows the inclination of the axis.

Table 2: Available settings for this row type


Bar chart

Last edited: 10/5/2017 11:51:06 AM

Shows the values of a selected observation property as a bar chart. This row type will only display content for feature types that have spatial support on observations.

Characteristic |
Typing | Features of one selected feature type can be bound
Binding | Any number of features or views. Each feature will be shown as a separate line in the chart.
Handling of container features | Container features that are not of the selected feature type will be expanded.

Table 1: Characteristics of this row type

Setting | Description
Feature type | The type of feature that will be shown in this row.
Observation property | The property whose value will be displayed. Only numeric properties can be selected.
Scale min | Defines the shown y-Axis interval. Default = 0
Scale max | Defines the shown y-Axis interval. Default = 100
Horizontal grid line count | Defines the number of horizontal grid lines that shall be shown.
Interpolation | Options: ·None ·To next ·To previoius

Table 2: Available settings for this row type


Empty

Last edited: 10/5/2017 11:51:14 AM

Defines a row without content. This row type might be useful if you need a place holder for manual modifications of the drawing.

Characteristic |
Typing | This row type does not display feature or observation data
Binding | This row type does not display feature or observation data
Handling of container features | This row type does not display feature or observation data

Table 1: Characteristics of this row type

Setting | Description
Placeholder text | Defines a text that will be shown in the content area of the row. Something like "This row is intentionally left blank"

Table 2: Available settings for this row type


Feature position

Last edited: 10/5/2017 11:51:16 AM

Displays the position of a feature or of an observation of this feature depending on the spatial support of the feature's type.

Characteristic | Description
Typing | Features of different types can be bound
Binding | Any number of features or views
Handling of container features | Container features are not expanded

Table 1: Characteristics of this row type

Setting

Description

Display type

Defines how the position is drawn. Options are:

·Text: The feature name or the feature name and the observation date (if spatial support is on observation) are shown.

·Symbol: Feature is shown as symbol

·Text & Symbol: The feature is shown as text plus symbol.

Default Text & Symbol

Text / symbol position

Defines where the text and/or symbol are shown. Options are:

·Left: Text and symbol are shown left aligned to the left marker

·Right: Text and symbol are shown right aligned to the right marker

·Center: Text and symbol are centered between left and right marker

Default: Center

Position markers

Defines the visual appearance of the position markers. Options are:

·No markers

·With arrow: The left marker is shown with a right-pointing arrow, the right marker with a left-pointing arrow. If left and right markers are at the same position a down-pointing arrow is shown.

·Without flag: Left and right position markers are simply displayed as lines

Default: With Arrow

Color overlapping positions

If set the colors used for the position markers are automatically changed if positions are overlapping.

Default: false

Symbol height

Defines the height of the symbol in millimeters. Only effective if display is set to symbol or text & symbol.

If the set height does not fit into the row the symbol is automatically scaled.

Default: 20mm

Validation: > 0.5mm ≤ 100mm

Status date

The date and time that is used to choose an observation from features with spatial support on observations.

The location shown will be the location of the observation nearest to this date. If not set the latest observation will be used.

Default: null

Date format

A date time format string that defines how date and time values are displayed.

Default: d

Used symbol

Defines which symbol is used if display is set to symbol or text & symbol:. Options are:

·Feature type: The symbol of the feature type is used

·Predefined: Use the selected predefined symbol

·Custom: Use the selected custom symbol

Default: Predefined

Predefined symbol

Defines the predefined symbol. Only used if Used symbol is set to Predefined.

Options are:

·Circle

·Rectangle

·Pyramid

·Cross

·Star

Default: Circle filled

Custom symbol

Defines the custom symbol. Only used if Used symbol is set to Custom. You can load any png file as custom symbol.

Default: empty

Table 2: Available settings for this row type


Line chart

Last edited: 10/5/2017 11:51:28 AM

Shows the values of a selected observation property as a line chart. This row type will only display content for feature types that have spatial support on observations.

Characteristic | Description
Typing | Features of one selected feature type can be bound
Binding | Any number of features or views. Each feature will be shown as a separate line in the chart.
Handling of container features | Container features that are not of the selected feature type will be expanded.

Table 1: Characteristics of this row type

Setting | Description
Feature type | The type of feature that will be shown in this row.
Observation property | The property whose value will be displayed. Only numeric and quantity properties can be selected.
Scale min | Defines the shown y-Axis interval. Default = 0
Scale max | Defines the shown y-Axis interval. Default = 100
Show data points | If set a symbol will be shown at each data point. The symbol type, size and color is defined by the binding setting
Break on null values | If set the line will be interrupted when the drawn observation property value is null. If not set observations with null values will not be shown.
Interpolation | Defines how values between data points are interpolated. Options are: ·Linear ·Step at beginning ·Step at end
Fill chart area | If set the chart area is filled
Grid line distance | Defines the distance between horizontal grid lines. Default 10 Validation >= 0 If zero no gridlines will be displayed
Position definition | Options are: ·Start offset ·Middle ·End offset Default: Middle

Table 2: Available settings for this row type


Measuring tape (alternating)

Last edited: 10/5/2017 11:51:28 AM

Displays a measuring tape with blocks of alternating color but no numbers that aids you in reading the drawing. This row type is especially useful in connection with the Measuring tape (numbers) row type.

Characteristic |
Typing | This row type does not display feature or observation data
Binding | This row type does not display feature or observation data
Handling of container features | This row type does not display feature or observation data

Table 1: Characteristics of this row type

Setting | Description
Interval | Defines the size of a block on this measuring type. Given in the unit of the drawing's axis reference system. Default: 20 Validation: > 0
Color 1 | Color 1 used for alternating blocks Default: Black
Color 2 | Color 2 used for alternating blocks Default: White

Table 2: Available settings for this row type


Measuring tape (numbers)

Last edited: 10/5/2017 11:51:28 AM

Displays a measuring tape tape with lines and numbers that aids you in reading the drawing.

Characteristic |
Typing | This row type does not display feature or observation data
Binding | This row type does not display feature or observation data
Handling of container features | This row type does not display feature or observation data

Table 1: Characteristics of this row type

Setting | Description
Interval | Defines the distance between two numbers on the measuring tape. Given in the unit of the drawing's axis reference system. The first number shown is calculated with following formula: Drawing start offset + Major Interval - (Drawing start offset % major interval) Default: 20 Validation: > 0
Ticks per interval | Defines how many ticks are shown between the numbers on the measuring tape. Ticks are not labeled with numbers. Default: 0 Validation: ≥ 0
Axis reference system | If set the number shown will be converted to the defined axis reference system. If null the numbers will be shown in the drawing's coordinate system. Default: null

Table 2: Available settings for this row type


Observation date

Last edited: 10/5/2017 11:51:30 AM

Displays the sampling timestamp or result timestamp of observations of the bound features.

If spatial support for the bound feature is on feature, only the latest date is shown.

Characteristic |
Typing | Features of any feature type can be bound
Binding | Any number of features or views
Handling of container features | Container features are not expanded

Table 1: Characteristics of this row type

Setting | Description
Shown time stamp | Options are: Sampling time stamp Result time stamp
Date format | The date format used when date and time values are shown.
Display type | Defines what text is shown. Options are ·Feature name & time stamp ·Time stamp
Text / symbol position | Defines where the text and/or symbol are shown. Options are: ·Left: Text and symbol are shown left aligned to the left marker ·Right: Text and symbol are shown right aligned to the right marker ·Center: Text and symbol are centered between left and right marker Default: Center
Position markers | Defines the visual appearance of the position markers. Options are: ·No markers ·With arrow: The left marker is shown with a right-pointing arrow, the right marker with a left-pointing arrow. If left and right markers are at the same position a down-pointing arrow is shown. ·Without flag: Left and right position markers are simply displayed as lines Default: With Arrow
Color overlapping positions | If set the colors used for the position markers are automatically changed if positions are overlapping. Default: false

Table 2: Available settings for this row type


Observation property value

Last edited: 10/5/2017 11:51:46 AM

Displays the value of a property in the extended observation property structure of a of a feature. If spatial support for the bound feature types is on feature the value of only one observation will be shown. This row type supports property types: Text, number, quantity, binary, classification. The value is always displayed as text.

Characteristic | Description
Typing | Features of one selected feature type can be bound
Binding | Any number of features or views
Handling of container features | Container features that are not of the selected feature type will be expanded.

Table 1: Characteristics of this row type

Setting | Description
Feature type | The type of feature that will be shown in this row.
Observation property | The property whose value will be displayed. Only properties on level 0 of the observation property structure can be used.
Date format | The date format used when date and time values are shown.
Display type | Defines what text is shown. Options are ·Value ·Feature name & value ·Feature name, Observation date & Value ·Observation date & Value
Image DPI | Defines the DPI of raster images if the shown value is an image. Note that the system will automatically scale the image to fit into the row, this setting defines number of pixels used. For smaller drawing sizes it is recommended that you use lower settings for DPI. Default: 150 Validation > 50 < 600
Maximum value text length | If numbers of characters needed to express the value of the observation property is greater than this number, the value will be shown truncated. Default: 100
Status date | The date and time used to define which observation's property value shall be shown if the spatial support of the feature type is on feature.
Text / symbol position | Defines where the text and/or symbol are shown. Options are: ·Left: Text and symbol are shown left aligned to the left marker ·Right: Text and symbol are shown right aligned to the right marker ·Center: Text and symbol are centered between left and right marker Default: Center
Position markers | Defines the visual appearance of the position markers. Options are: ·No markers ·With arrow: The left marker is shown with a right-pointing arrow, the right marker with a left-pointing arrow. If left and right markers are at the same position a down-pointing arrow is shown. ·Without flag: Left and right position markers are simply displayed as lines Default: With Arrow
Color overlapping positions | If set the colors used for the position markers are automatically changed if positions are overlapping. Default: false

Table 2: Available settings for this row type


Spherical projection

Last edited: 10/5/2017 11:51:42 AM

This row type can be used to display the spherical projection of planes. For using this row type you have to have a feature with two numerical properties in the observation property structure expressing either dip direction and dip or strike and dip. A third classification property can be used to classify the planes according to the setting of this property.

Usually you will use this row type with a data-combination, i.e. you will combine the planes from a section in the tunnel in one spherical projection diagram.

Characteristic | Description
Typing | Features of one selected feature type can be bound
Binding | Any number of features or views
Handling of container features | Container features that are not of the selected feature type will be expanded.

Table 1: Characteristics of this row type

Setting | Description
Feature type | The type of feature that will be shown in this row.
Observation property | The property whose value will be displayed. Only properties on level 0 of the observation property structure can be used.
Date format | The date format used when date and time values are shown.
Display type | Defines what text is shown. Options are ·Value ·Feature name & value ·Feature name, Observation date & Value ·Observation date & Value
Image DPI | Defines the DPI of raster images if the shown value is an image. Note that the system will automatically scale the image to fit into the row, this setting defines number of pixels used. For smaller drawing sizes it is recommended that you use lower settings for DPI. Default: 150 Validation > 50 < 600
Maximum value text length | If numbers of characters needed to express the value of the observation property is greater than this number, the value will be shown truncated. Default: 100
Status date | The date and time used to define which observation's property value shall be shown if the spatial support of the feature type is on feature.
Text / symbol position | Defines where the text and/or symbol are shown. Options are: ·Left: Text and symbol are shown left aligned to the left marker ·Right: Text and symbol are shown right aligned to the right marker ·Center: Text and symbol are centered between left and right marker Default: Center
Position markers | Defines the visual appearance of the position markers. Options are: ·No markers ·With arrow: The left marker is shown with a right-pointing arrow, the right marker with a left-pointing arrow. If left and right markers are at the same position a down-pointing arrow is shown. ·Without flag: Left and right position markers are simply displayed as lines Default: With Arrow
Color overlapping positions | If set the colors used for the position markers are automatically changed if positions are overlapping. Default: false


CAD map

Last edited: 12/6/2017 6:27:08 AM

The CAD map allows the GIS-like graphical presentation of features, observations and other spatially located elements in CAD file formats. It visualizes data using the stored spatial data using a projected spatial system. The CAD view is able to transform data from different spatial reference systems to the one specified projected system.


Cad map definition

Last edited: 12/6/2017 7:15:18 AM

Before a CAD map can be rendered the the content and the layout has to be defined. These elements make up the CAD map definition. CAD map definitions can then persisted as CAD map templates for later reuse.

The options for defining the layout and content of a CAD map can be logically structured into the sections described in table 1.

Definition | Description
Map configuration | A UConfiguration containing settings that affect the CAD map as a whole. These settings do not influence what is drawn but mainly how things are drawn.
Data filter | If the map view displays observations the data filter can limit the observations actually rendered.
Contents | Contents define what data is rendered into the CAD map and how that data is visualized. Each content is an instance of a predefined content type. Each of these types has its own UConfiguration with settings that allow you to fine tune what is shown and how things are visualized.

Table 1: Logical structure of a CAD map definition


Content types

Last edited: 12/6/2017 7:15:38 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Reporting

Last edited: 10/5/2017 11:51:34 AM

A report can present data using a combination of text, charts, maps and other graphical elements. Reports are prepared for printing or digital archiving in form of PDF or other file formats.

In most cases reports will iterate over the feature data and observations of a set of features and will render this data in form of text or graphics. Reports can also include (link) charts and map views.

Reports are generated based on a report definition, and each report definition is based on a predefined report type. Each report definition consist of the data listed in table 1. As all other presentation types reports can be stored as templates. Most report types restrict the bindings to bindings of a specific feature type.

Reports are always generated on the Application Server the resulting files can be provided as Application Server Output Files or can be published to other destinations.

Data | Description
General settings | Settings available for every report type
Type specific settings | Settings specific to the chosen report type
Observation filter | A static or dynamic time filter that can limit the observations shown in the report. These settings are of course only used if the report iterates over observations.
Bindings | The features for which the report will be created.

Table 1: Contents of a report definition.


General settings

Last edited: 10/5/2017 11:51:20 AM

The general settings of a report definition are common to all report types and specify how a report is created and where it is stored.

Setting name

Description

Output format

Defines which file format will be used to store the generated reports. You can choose between following formats:

·PDF: Adobe Portable document Format Version 1.6

·DOCX: Renders a report in Microsoft Word 2007 format (also known as OpenXML) - it is a zipped, XML-based file format developed by Microsoft for representing word processing documents.

Split content

This setting can be used to split the report into multiple files. Following options are available:

·Do not split: The report will be saved as single file

·Split by feature: Each feature in a report will be saved in a separate file.

·Split by observation: Each observation will be saved as a separate file.

Table 1: Settings affecting the report generation

Setting name | Description
Save in output files | If selected the Application Server will store the created reports in the Output files.

Table 2: Settings affecting the publishing of report files to Application Server Output files

Setting name | Description
Publish to FTP | If selected the Application Server will publish the created reports to an FTP Server
FTP Server | Address of the FTP Server (DNS or IP)
Port | The port of the FTP Server
Passive | If set advices the Application Server to user passive FTP mode when connecting to the FTP Server
Timeout | The timeout used for connecting to the FTP server.
Username | The username for authenticating against the FTP server
Password | The password for authenticating against the FTP server.
Path | The path on the FTP Server where the report files shall be copied to.

Table 3: Settings for copying the report files to an FTP server

Setting name | Description
Publish to document folder feature | If selected the Application Server will publish the created files to a document folder feature.
Folder feature | The document folder feature in which the report files will be published.
Use versioning | If selected following logic will be used when publishing files to the document folder: If a document with the same name as the new report document is already in the document folder the new report document will be published as new version of this document feature. If not selected each report will be published as a new document feature.

Table 4: Settings for copying the report files to a document folder feature

Setting name

Description

Name template

This text template will be used as for determining the filenames for created report files. The text template defines only the filename without extension.

For more information on how this text template is used refer to chapter Text templates for report file names.

Table 5: Settings influencing the naming of the report files

Setting name | Description
Include erroneous | If set the reports will include observations marked as erroneous. If not set these observations will not be shown in the report.

Table 6: Miscellaneous settings


Text templates for report file names

Last edited: 10/5/2017 11:51:44 AM

The files created by the reporting engine are named according to the provided text template. If the provided text template is empty the Application Server will automatically choose file names. If the provided template is evaluated to an empty string the Application Server will generate random filenames for report files.

In addition to the general variables available with every text template the additional markup variables are available for the report file name text template. Table 1 shows these additional variables.

Variable name | Description
ReportTypeName | Name of the executed report type
TemplateName | Name of the presentation template from which the report was created. Empty if the report was not created from a presentation template.
FeatureName | Name of the feature for which the report is created. If report is created more than one feature and the Split content report setting is set to do not split this variable will be empty.
AxisName | Name of the axis that is used by the feature for which the report is created. If feature does not use a spatial system of type axis reference system this variable will be empty. If report is created more than one feature and the Split content report setting is set to do not split this variable will be empty.
AxisReferenceSystemName | Name of the axis reference system that is used by the feature for which the report is created. If feature does not use a spatial system of type axis reference system this variable will be empty. If report is created more than one feature and the Split content report setting is set to do not split this variable will be empty.
ObservationSamplingTimestamp | Sampling timestamp of the observation for which the report is generated. If report is created more than one observation and the Split content report setting is set to do not split or split by feature this variable will be empty.
AxisOffsetFrom | Position of the feature or observation (depending on the spatial support of the feature) for which the report is generated.
AxisOffsetTo | Position of the feature or observation (depending on the spatial support of the feature) for which the report is generated.

Table 1: Additional variables for text templates available for report file naming


Report bindings

Last edited: 10/5/2017 11:51:34 AM

Report bindings bind features to a report definition. The report type may (and will in most cases) limit the bindings to bindings of ones specific feature type only.

When the report definition is executed the reports will usually be created for all bound features.

Features can be bound to report definitions directly via container features or via views. Container features and views are expanded into features when the report is executed. If the report type limits bindings to one specific feature type only those features that match the feature type will be expanded.


%Text%

Navigation: Application Server > Presentation >

Spherical projection

Last edited: 10/5/2017 11:51:42 AM

Different types of spherical projections can be used for visualizing and evaluating the tree dimensional orientation of planes and lines on a two dimensional surface (screen, paper). Redbex supports the visualization of different types of lower hemisphere of spherical projections. These visualizations are used in Axis section drawings and Reports.

A spherical projection shows where lines or planes intersect the surface of a (hemi)sphere, provided that the lines/planes also pass through the center of the (hemi)sphere. The projection of these intersections can be done in different ways, the two ways commonly used in structural geology (and also the two ways supported by Redbex) are Equal-Angle Projection (or stereographic projection) and Equal-Area projection (or Lambert azimuthal projection).

It is common for spherical projections to show a net (i.e. grid) that allows for better interpretation of the drawn intersections. This grid shows the projection of planes through the center of the sphere with an azimuth of 0° and varying dip, as well as the projection of planes with a dip of 90° and orthogonal to the North south axis in varying distances from the center of the sphere.

A circle on a sphere whose plane passes through the center of the sphere is called a great circle; otherwise it is a small circle. Circles of a sphere have radius less than or equal to the sphere radius, with equality when the circle is a great circle.

Equal-Angle Projection (=Stereographic projection)

This type of projection preserves angular relation ships. I.e. the angle between the tangent of two intersecting great circle traces at their point of intersection is the same as the angel the two real planes the great circle traces represent. The Equal-Angle Projection does not conserve area. I.e. projections of identical circles described on different parts of a projection sphere appear as circles of different sizes.

The grid used for manual drawing of an equal angle projection on paper is called a Wulff net.

Equal-Area projection (=Lambert azimuthal projection)

This type of projection conserves area, i.e. identical circles on the projection sphere project as ellipses with various axisal ratios but having the same area. The Equal-Area projection however does not conserve angular relation ships.

A grid constructed on an equal area projection is called a Schmidt net.

Property | Equal-Angle projection | Equal-Area projection
Net type | Wulff net | Schmidt net
Projection preserves | Angles | Areas
Projection does not preserver | Areas | Angles
A line is projected as | Point | Point
A great circle is projected as | Circle | Ellipsis
A small circle is projected as | Circle | Ellipsis
Best use | Measuring angular relations | Statistical evaluation Contouring orientation data

Table 1: Summary of characteristics of different spherical projections

Visualization types

Independently of the chosen type of spherical projection Redbex support 3 different ways of displaying a plane on the projection:

·Great circle: Shows the projection of the intersection of the plane with the lower hemisphere

·Pole Point: Shows the intersection of a line orthogonal to the plane through the center of the sphere, with the lower hemisphere.

·Contour lines: Shows contour lines that visualize the distribution of pole points on the projection.

Note that while Redbex can visualize the distribution of pole points as contour lines on a Equal angle projection that kind of visualization should not be used for statistical analysis.


Common services

Last edited: 4/3/2018 3:17:30 PM

The Application Server's common services provide the infrastructure around content, structure, processing and presentation.


Authentication

Last edited: 11/8/2017 9:24:06 AM

Authentication is the process that ensures that a party trying to access the Application Server is really the one it claims to be. In Redbex authentication is based on a username/password principle. Authentication should not get confused with login, authentication is only part of the login process but is also used in other parts of the system e.g. in approval.

To authenticate against the system, the accessing person or system has to provide a username that matches the name of a user in Redbex and a password.

Basis for authentication is a user account in the Redbex system, i.e. each user of the Redbex system must have a user account within the system. The actual authentication i.e. the matching of username and password is performed according to the Authentication type setting of the user. Table 1 describes the authentication types available.

Authentication type | Description
Application Server | The given username is matched against the list of users in Redbex. If a match is found the hash calculated on the given password string is compared with the hash stored along with the user in the Application Server. If hashes match the user is authenticated.
Active directory | The given username is matched against the list of users in Redbex. If a match is found the username and the given password are forwarded to the LDAP directory of a Microsoft Active Directory using the LDAP or LDAPs protocol. The LDAP server will then validate the password.

Table 1: Supported Authentication types

Irrespective of the used authentication type the given username is case insensitive, the password is case sensitive. The system automatically truncates trailing and leading white space from the given username and password.

When using Application Server authentication type the system does not store passwords as clear-text or as encrypted string but as hash using SHA256 hashing algorithm and to provide additional protection against dictionary attacks the system uses salting. Because of this there is no way of determining the password of a user except brute force guessing.


Password quality rules

Last edited: 10/5/2017 11:51:30 AM

To enhance authentication security the Application Server can enforce rules on the quality of user passwords when using local authentication. The quality of a password expresses how hard it is to guess the password or determine the password with brute force attacks. These rules are checked whenever the password for a user is changed.

Password security rules can be configured in the global settings. Table 1 lists the settings that define the password quality rules enforced by the system.

Although we do not recommend to allow empty passwords, you can allow empty passwords by setting Password quality: Minimum length to zero and disabling the rules Password quality: Must include digits, <%GS_PASSWORDRULECHECKFORLOWERCASEUPPERCASE%> and Password quality: Must include special character.

Rule | Description
Password quality: Minimum length | Defines the minimum length (number of characters) a password must have. We do not recommend to use values lower than 8 for this setting. Default: 8
Password quality: Must include digits | If enabled, passwords must contain at least one digit [0-9] Default: Enabled
Password quality: Must include lower and upper-case letters | If enabled passwords must contain at least one letter out of the range [a-z] and one letter out of the range [A-Z] Default: Enabled
Password quality: Must include special character | If enabled passwords must contain at least one the following characters !,§,@,#,$,%,^,&,*,?,_,~,-,£,(,) Default: Enabled
Password quality: Must not contain username | If enabled, passwords are not allowed to contain the username. This rule is checked case insensitive. Default: Enabled
Password quality: Must not contain name | If enabled, passwords are not allowed to contain the user's first, middle or last names. This rule is checked case insensitive. Default: Enabled

Table 1: The global settings defining the password quality rules enforced by the Application Server


Repeated authentication failure

Last edited: 10/5/2017 11:51:34 AM

The Application Server can be configured to prevent authentication fraud by systematically guessing usernames and/or passwords. It does this by detecting situations of repeated authentication failure and taking actions that hinder the systematic guessing of username and password. It depends on the configuration of your system weather actions are taken when one of these situations is detected or not. Any action taken on detection of these situations is logged in the system log.

Repeated authentication failure with non existing username

When the system detects more than a configurable number of consecutive login failures with unknown user names the answer to a authentication attempt can be delayed. The delaying is intended as protection against password guessing attacks.

The delay time is calculated by following formula:

delay = FailedAttemptsWithUnknownUserCount - AuthenticationDelayThreshold) * 2

The delay will affect all authentication attempts (from any client). A successful login will reset the counter for failed attempts. A shutdown of the Application Server will also reset the counter for failed attempts.

The number of consecutive failed authentication attempts after which the slow down will occur (AuthenticationDelayThreshold) is configured with the global setting User sessions & security: Authentication slowing threshold.

Repeated authentication failure with the same existing username

When the system detects repeated login failures for the same username and if this username refers to an existing user account the user can be locked after a configurable number of repeated login failures.

The number of consecutive failed authentications for one user after which the user will be locked is configured with the global setting User sessions & security: Authentication locking threshold. If a user is locked he is not able to create a new user session and can therefore not logon to the system. A successful login resets the counter of failed authentications to zero. A shutdown of the Application Server will also reset the counter for failed authentications.

The counters for repeated consecutive login failures (total and for each user) are reset when the Application Server is restarted.


Password aging

Last edited: 10/5/2017 11:51:30 AM

Password aging is the concept that forces a user to periodically change his or her password. If the password is not changed within a specific amount if time, it expires and must be changed. The idea behind password aging is that a password is less likely to be compromised if it is changed regularly.

For users with local authentication the Application Server can enforce password aging with a configurable maximum password age.If a password has expired (the password was not changed within the predefined maximum password age) the user cannot create a new session. However he can authenticate by giving his old password and at the same time set a new password.

The maximum password age is configured by the global setting User sessions & security: Maximum password age [d]. This setting gives defines the maximum password age in days. Setting the User sessions & security: Maximum password age [d] to zero will disable password aging. Whenever a password is changed the system checks this global setting, if it is greater than zero the new password's expiry date will be set to CurrentTimestamp + MaximumPasswordAge. Therefore changing this setting will not affect already set password expiry dates.

Users with the Manage users and user groups (0) system permission can set the password expiry date of each user to a specific date.

For newly created users Redbex will set the password expiry date to a date in the past, so that on the first login a user will always have to change his password.


Changing password

Last edited: 10/5/2017 11:51:08 AM

In order to change password user needs to authenticate himself with his old password and provide a new one, changing passwords is only possible for users with local authentication type. The new password must confirm to the set Password quality rules. Additionally the new password must be different from the old password.

A password change can be initiated by the user himself or can be forced by password aging.

If password change was successful the validity of new password is set to the current date and time plus the number of days set with the Global Setting User sessions & security: Maximum password age [d].


Setting / Resetting a password

Last edited: 10/5/2017 11:51:34 AM

Users with the system permission Manage users and user groups (0) can request a new password for another users. This will reset the user's password to a new randomly generated password. The new password will then be sent to the e-mail address stored with the user account. A password can therefore only be reset if an email address is specified for the user.

The user who is requesting the password reset cannot set a specific password, and the random password that the system chooses is never shown to the user who is requesting the reset. Therefore the only one who knows the password is the user himself.

A user cannot request a reset of his own password. See changing password for information on how to change your own password.

The new password assigned to a user when a password reset is requested will conform to the set password quality rules. The newly generated password will have a minimum length of 8, regardless of the global setting for Password quality: Minimum length.

The Application Server will set the new password as expired, thus forcing the user to change his password on the next login.


Authentication log

Last edited: 10/5/2017 11:51:04 AM

Each authentication attempt (successful or not) is logged by the system for later evaluation. If the authentication was successful and resulted in the creation of a user session the authentication attempt is connected with that user session The authentication history can only be read by users with the system permission Read authentication log (6).

The authentication log can be purged to delete the entries of unsuccessful authentication attempts. The authentication history can be purged by users with the system permission Purge authentication log (7).

Purging will delete all authentication log entries created in a given time span that are not connected to a user session i.e. authentication log entries of unsuccessful authentication attempts..


Authorization

Last edited: 10/5/2017 11:51:04 AM

Authorization is the function of specifying access rights to resources. The Application Server implements an authorization model based on privileges that grant access to content, structure and services of Redbex.

A privilege defines a permission that a specific user or a specific user group is granted on a specific object.

The authorization model used in the Application Server is additive, i.e. a user has no permissions on any resource if no permission was granted through a privilege. Newly created users have no privileges by default.

Redbex does not have negative privileges that can take away permissions granted through another privilege.


Privileges

Last edited: 11/8/2017 9:24:20 AM

A privilege is the combination of a permission, a privilege object on which the permission is granted and a privilege subject (a user or a user group) to whom the permission is granted. Permissions can only be granted through the definition of privileges.

Privileges define the permissions that a privilege subject has on a privilege object, the permissions granted through a privilege with a specific privilege object can implicitly give permissions on other privilege objects through privilege inheritance and privilege transformation.

·Through privilege inheritance the permission granted in a privilege may be propagated to subordinate privilege objects. Privilege inheritance is used with view privileges, domain privileges and feature privileges.

·Through privilege transformation a permission granted on a privilege object can imply another permission on a (possibly) different privilege object.

§E.g. The view permission Modify features on a view privilege object is transformed to the feature permission Modify on all members of the view. Privilege transformation is transitive.

§E.g. The view permission Modify subordinate views on a view privilege object is transformed into the view permission Modify on all subordinate views

Figure 1 shows privilege inheritance and transformation paths for all privilege object types. Note that the effective permission a given user has on a specific object will also include all permissions that any user group that the user is member of is given on that specific object.

Indirect permissions that are available for some privilege object types affect objects that are linked to the privilege object but are not privilege objects themselves. E.g. the Modify classification permission that can be granted on a domain does not affect the domain itself but only classifications that are member of that domain.

The access to some objects of the Application Server that are secured by combined privileges. I.e. the access is regulated by granting related permission on two different privilege object types. E.g. a user can only create or modify a feature subtype for a specific feature type in a domain if he has the domain permission Modify feature subtypes (14) and the feature type permission Modify feature subtypes (3). Figure 1 shows possible combined privileges.

Figure 1: Inheritance, transformation and combination of privileges.

Privilege object

Inherits from

Gets transformed permissions from

Feature type

System permission

Feature

If a feature is member of a platform feature it inherits all permission from that platform feature.

If a feature is instantiated from a calculated feature it inherits all permissions from that instantiating calculated feature.

View permissions that affect all member features are transformed to the corresponding feature permissions.

Views

Permissions on all parent views (in the view's path) are inherited.

The system permission All permissions on root views (1) is transformed into all available view permissions on all root views.

The System permission List all Features (27) is transformed into a List features (2) on every view.

The view permission Modify subordinate views (5) is transformed into the view permission Modify view (0) on all subordinate views

Domain

All domain permissions except Read (0) are inherited to subordinate domains.

Read (0) is inherited to all parent domains.

If a user has feature permission Read (0) permission that permission is transformed into the domain Read (0) on the domain the feature belongs to.

System

Table 1: Inheritance and transformation of permissions.


%Text%

Navigation: Application Server > Common services > Authorization > Privileges >

Privilege object types

Last edited: 11/8/2017 9:27:46 AM

The privilege object is the entity on which permissions are granted through a privilege. There are several types of objects in Redbex that can be used a privilege objects.Table 1 lists the these objects types. Note that one privilege can only have one privilege object.

A privilege with a view as privilege object is called a view privilege, a privilege with a feature as privilege object is called a feature privilege, a.s.o.

Privilege object type | Notes
System | Represents the system a a whole. There is only one system privilege object. Used to grant global permission. See chapter System privileges & permissions for details.
Feature | Used to assign permission to specific features See chapter Feature privileges & permissions for details.
View | Used to assign permission to views and to the features contained in that views (through privilege transformation). See chapter View privileges & permissions for details.
Domain | Used to assign permissions for domains. Domain permissions also control access to many indirect privilege objects that are assigned to domains. E.g. Classifications, Axes, etc. See chapter Domain privileges & permissions for details.
Feature type | Used to assign permissions that apply to indirect privilege object types like sensors and classifications, that are referenced to feature types. See chapter Feature type privileges & permissions for details.

Table 1: Available privilege object types


%Text%

Navigation: Application Server > Common services > Authorization > Privileges >

Privilege subject

Last edited: 11/8/2017 9:24:20 AM

The privilege subject defines whom a privilege is granted to i.e. which users the permission contained in the privilege is granted to. The privilege subject can be a either a specific user or a specific user group.

If the privilege subject is a user group the users who have this privilege are evaluated when the privilege is queried by the system. I.e. by changing the members of a user group the effective privileges for the users might change. Note that group membership is propagated upward in the user group tree. Therefore if a user is member of a subgroup and a certain permission is granted to parent group, user gains this permission as well. E.g. if group B is subgroup of group A and user C belongs to group B, all privileges where the privilege subject is group A will result in permissions for user C.

Using user groups as privilege subjects is advisable since it allows you to easily grant the same permissions to groups of users with minimal configuration work and allows consistent changes of permissions.


%Text%

Navigation: Application Server > Common services > Authorization > Privileges >

Permission

Last edited: 11/8/2017 9:27:08 AM

Objects (like features, domains etc) managed by the Application Server demand specific permissions to be accessed (i.e. read, modified, etc). Each privilege grants exactly one permission to one specific privilege subject on one specific privilege object. Each privilege object type has its own set of permissions that can be granted.

Besides its name each permission has a number. This should help you identifying the right permission if you are reading this Reference Manual but your Application Server Language or Client language is not set to English.


%Text%

Navigation: Application Server > Common services > Authorization > Privileges >

Effective permissions

Last edited: 10/5/2017 11:51:14 AM

The effective permissions are all the permissions a specific user has on a specific privilege object. The effective permissions might be inherited from parent objects or the privilege object, might be inherited from a user group the user belongs to, or might be transformed from privilege objects of other types.


%Text%

Navigation: Application Server > Common services > Authorization >

Privileges for Privileges

Last edited: 11/8/2017 9:24:26 AM

In Redbex it is not necessary that privileges are managed by one central administrator. If a user can grant, delete, modify or query privileges on specific privilege object is determined by several rules explained in the following chapters.


Granting privileges

Last edited: 11/8/2017 9:27:40 AM

If a user can grant a privilege on a specific privilege object is determined by several rules depending on the privilege object type. Below you find the rules that have to be matched for removing privileges from different privilege object types.

System privileges

A system privilege can be granted by a user if all of the following conditions are matched:

1.The user who tries to grant the privilege has the Modify system privileges (2) system permission.

2.The permission that is granted through the privilege to is granted to the user who tries to grant a privilege.

View Privileges

A view privilege can be granted for views if all of the following conditions are matched:

1.The user who tries to grant the privilege has the Modify view privileges (4) permission on the view that is privilege object of the privilege to be granted.

2.The user who tries to grant the privilege has the permission he is trying to grant through the new privilege himself. Note that the permissions on root view can be transformed from the system permission All permissions on root views (1).

Domain privileges

A domain privilege can be granted if:

1.The user who tries to grant the privilege has the Modify privileges (3) permission on the domain that is the privilege object.

2.The user who tries to grant the privilege has the permission that he is trying to grant himself on the domain that is the privilege object.

Feature privileges

A feature privilege can be granted if:

1.The user who tries to grant the privilege has Modify privileges (8) permission on that feature.

2.The user who is trying to grant the new privilege, must have the permission in that privilege on the feature himself

Feature type privileges

A feature type privilege can be granted if:

1.The user who tries to grant the privilege has the Modify feature type privileges (23) system permission modify feature type privileges.

2.The user who tries to grant the privilege has the permission that he is trying to grant himself on the feature type that is the privilege object. Note that you can use the All permissions on feature types system permission to grant all feature type permissions on all feature types to a permission subject.


Removing privileges

Last edited: 11/8/2017 9:27:40 AM

If a user can remove a privilege on a specific privilege object is determined by several rules depending on the privilege object type. Below you find the rules that have to be matched for removing privileges from different privilege object types.

Regardless of the privilege object a privilege can never be removed if the removing user is the privilege subject of the privilege to be removed. This is checked to prevent an accidental self lock outs.

System privileges

A system privilege can be removed if all of the following conditions are true

1.The user who tries to remove the privilege has the Modify system privileges (2) system permission.

2.The permission in the privilege to be removed is granted to the user who tries to remove the privilege.

View Privileges

A view privilege for a non-root view can be removed if all of the following conditions are true

1.The user who tries to remove the privilege has the Modify view privileges (4) permission on the view that is privilege object of the privilege to be granted.

2.The user who tries to remove the privilege has the permission he is trying to remove through himself.

Note that permissions on root views can be transformed from the system permission All permissions on root views (1).

Domain privileges

A domain permission can be removed if:

1.The user who tries to remove the privilege has the Modify privileges (3) permission on the domain that is the privilege object.

2.The user who tries to remove the privilege has the permission that he is trying to remove himself on the domain that is the privilege object.

Feature privileges

A feature privilege can be removed if all of the following conditions are matched:

1.The user who tries to grant the privilege has Modify privileges (8) permission on that feature.

2.The user who tries to remove the privilege has the permission that he is trying to remove himself on the feature that is the privilege object.

Feature type privileges

A feature type privilege can be removed if:

1.The user who tries to remove the privilege has the system permission Modify feature type privileges (23).

2.The user who tries to remove the privilege has the permission that he is trying to remove himself on the feature type that is the privilege object .


Querying privileges

Last edited: 10/5/2017 11:51:34 AM

The privileges defined for a specific privilege object (optionally with inherited privileges) and the effective privileges that a specific user or user group has on a specific privilege object can be queried from the Application Server.

However for querying privileges the the querying user also needs specific permissions. These permissions depend on the privilege object type, table 1 lists the required permissions.

Privilege object type | Permissions required
System | none; every user can query privileges and effective permissions of any user or user group on the system privilege object.
Domain | The accessing user must have Read (0) rights for the queried domain.
View | The accessing user must have List views (3) permission for the queried view
Feature | The accessing user must have Read (0) rights for the queried feature
Feature type | none; every user can query privileges and effective permissions of any user or user group on any feature type;

Table 1: Permissions needed to query privileges and effective privileges


%Text%

Navigation: Application Server > Common services > Authorization >

Privilege object types & Permissions

Last edited: 11/8/2017 9:27:08 AM

Each privilege object type has its own set of permissions that can be granted to a privilege subject. following chapters list and explain the available permissions.


System privileges & permissions

Last edited: 5/3/2018 6:44:50 AM

System privileges define permissions users have on the system as a whole. The system privilege object is special in that there is only one system object and therefore no privilege object has to be selected when granting system permissions.

Permissions granted for the system privilege object can be thought of as global permissions. Table 1 lists the available system permissions.

System permissions are not inherited, and not transformed from other privilege objects. System permissions are transformed into other permissions on other privilege objects.

Permission name

No

Description, Actual actions granted

Manage users and user groups (0)

0

Create, modify and delete users and user groups. Reset user passwords, manage user password expiry.

Assign users to user groups, remove users from user groups.

Note: A user can only be added to a user group if the user performing this action has this permission and if the user performing this action has all the permissions that the user would get through the user once he is assigned.

All permissions on root views (1)

1

Create new root views.

This permission is transformed into all available view permissions on all root views and therefore through inheritance on all views.

This is a strong permission that has implications on the access to all data stored with features and observations. It is advised to use this permission sparingly.

Usually you should grant this permission only to users who really need to manage root views.

Modify system privileges (2)

2

Grant or revoke privileges with the system as privilege object.

Even if this permission is granted only privileges with permissions granted to the accessing user can be granted or revoked.

A user cannot revoke permissions assigned to himself.

Close user sessions (3)

3

Close the user sessions of other users and therefore kick them from the Application Server.

Modify global settings (4)

4

Modify the values of global settings.

Purge fully deleted messages (5)

5

Allows to purge all deleted messages that were deleted by all recipients and the sender.

This permission is only needed for users who administrate the system and do regular cleanups.

Read authentication log (6)

6

Permission to read the authentication log.

This permission is usually only needed by users who monitor the system for security issues.

Purge authentication log (7)

7

Permission to delete old entries in the authentication log.

This permission is only needed for users who administrate the system and do regular cleanups

Perform Distribution Server update (8)

8

Allows to fetch and install updates from the Distribution Server can be installed.

List all jobs (9)

9

List all jobs (in any job state) no matter who the job owner is.

Manage jobs (10)

10

Manage all jobs irrespective which user owns them.

Even if this system permission is not granted to a user, that user can still manage his own jobs (jobs started by this user).

This permission is usually only needed by users who want to monitor and manage the jobs and the load these jobs put on the system.

Purge archived jobs (11)

11

Delete the archived jobs i.e jobs that are finished.

Only needed by users who perform housekeeping on the Application Server.

Read user sessions (12)

12

Read the user session log.

Even if this permission is not granted a user can always read his own user session history.

Create user session when server is closed (13)

13

Create a user session (and therefore) logon to the Application Server even if server is closed.

Will only be needed by a few users, who want to perform housekeeping tasks while it is guaranteed that no other users are logged on.

List all approvals (14)

14

List all approvals.

Use privileged job priorities (16)

16

Create jobs with privileged priorities.

Purge features and observations (17)

17

[unused]

Purge user session log (18)

18

Purge the user session log.

Only needed by users who perform housekeeping on the Application Server.

List all observation alarms (19)

19

If this permission is granted the user can list all observation alarms (of all users for all features)

Acknowledge all observation alarms (20)

20

Acknowledge all observation alarms even if the user has no acknowledging obligation.

Grant this permission to users who should be able to clean up unhandled acknowledgement requests.

Manage personal stored job definitions (21)

21

Can create stored job definitions.

Stored job definitions that run at a regular schedule might put a huge load on the system. Therefore you can use this permission to allow only specific users to create stored job definitions.

Manage stored jobs definitions (22)

22

If granted allows a user to manage stored job definitions owned by other users.

Modify feature type privileges (23)

23

Grant and revoke privileges on feature types.

Even if this system permission granted the user can only grant or revoke privileges with permissions that he is granted himself.

Manage coordinate systems (24)

24

Create and modify coordinate systems that are used as reference system for features and observations with spatial support.

All permissions on feature types (25)

25

Is transformed into all available feature type permissions on all feature types.

Modify general text templates (26)

26

Modify general text templates, like the templates used for sending out login details via email.

List all Features (27)

27

If granted, the user can list all features.

Manage message forwarding rules (28)

28

If granted, the user can create and modify message forwarding rules for other users and global message forwarding rules.

Table 1: Permissions that can be granted to the system privilege object


Domain privileges & permissions

Last edited: 11/8/2017 9:27:28 AM

Permissions for domains control access to the domains and many indirect permission objects linked to domains e.g. axes, or cross sections.

Domain privileges granting the domain permission Read (0) are propagated up and down the domain tree. I.e. if the Read (0) is granted to a domain the privilege will also apply to all of the domains on the path of this domain. The Read (0) permission is always granted to all users on the root domain, however that specific permission is not propagated down the tree.

Domain privileges granting any other domain permission than Read (0) are propagated down the domain tree. I.e. if the privilege is granted to a domain the privilege will be inherited by all subordinate domains.

Read permissions of features that are member of a domain are transformed to a read permission on the domain itself, therefore whenever a read permission is given on a feature (either directly or transformed from a view permission) this will automatically imply read permission on the domain

Table 1 lists the permissions that can be granted for domains and effect the domains themselves, table 2 lists indirect permissions that are granted on domain as privilege objects but define the access rights on indirect privilege objects linked to the domains.

Permission

No

Description, Actual actions granted

Read (0)

0

Read all data of the domain, including

·Sensors

·Classifications

·Axes and axis reference systems

·Presentation templates

·Alias schemes

·Approval templates

·...

and all other data liked to a domain. Does not include the right to read all features linked to that domain.

Note that read permission on a domain is implicitly granted to a user if that user has read permission on one of the features belonging to that domain.

Modify (2)

2

Modify data of the domain. Includes the permission to:

·delete domains (except root domain which cannot be deleted).

·create subordinate domains.

·set privilege propagation break

·hide feature types

Note that deleting of domains is only possible if no other data is linked to that domain.

Modify privileges (3)

3

If granted the privilege subject can modify the privileges on that domain. However the privilege subject can only add or remove privileges that it is granted itself.

Table 1: Permissions on domains

The permission to read data linked to a domains (except features) is either granted directly by granting the Read permission or indirectly by the system If a user has the permission to read a feature or some other content that is assigned to a specific domain the system will implicitly grant the right to read all other content except features in the same domain or a parent domain thereof.

Permission | No | Description
Hide feature types (6) | 6 | Hide specific feature types in this domain. Will restrict the feature types that are available when creating new features in that domain.
Manage alias schemes (7) | 7 | Create modify and delete alias schemes. This permission does not implicitly allow to translate features names in a scheme - alias names for a feature can only be modified if the user has modify permission on the feature.
Manage axes (10) | 10 | If granted axes and axis reference systems can be created and modified in the domain.
Manage presentation templates (9) | 9 | If granted presentation templates can be created and modified in this domain
Observation monitoring (8) | 8 | If granted you can create monitoring definitions on a feature type in that domain given that you also have the Modify feature settings (4) on that feature type.
Permission | No | Description

Table 2: Permissions on on domains that effect indirect privilege objects

Permission

No

Description

Create features (4)

4

Permission to create features that are member of this domain. To actually be allowed to create a feature the feature type permission Create features of this type has to be granted also.

Note if there is no view containing the newly created feature that assigns permissions to the creating user, the user might be able to create a feature but can not read or modify it

Modify approval templates (11)

11

Permission to create, modify and delete approval templates that are member of a specific domain.

To be allowed to actually create, modify or delete an approval template the user also needs modify approval templates permission on the feature type the approval template references.

Modify Classifications (13)

13

Permission to create modify and delete classifications that are member of a specific domain.

To be allowed to actually create, modify or delete a classification the user also needs modify classifications permission on a feature type that uses classifications of that classification type.

Modify feature settings (15)

15

Modify feature settings where the context is a feature setting with a context that reference a specific domain.

To be allowed to actually create, modify or delete a feature setting the user also needs modify feature settings permission on feature type the setting context references.

Modify feature subtypes (14)

14

Propagation direction: down

Permission to create modify and delete feature subtypes within that domain.

To be allowed to actually create, modify or delete a feature subtype the user also needs modify feature subtypes permission on the feature type the subtype belongs to.

Modify sensors (12)

12

Permission to create, modify and delete sensors that is member of a specific domain.

To be allowed to actually create, modify or delete a sensor the user also needs modify sensors permission on the feature type the sensor belongs to (via its sensor type).

Modify sensor settings (16)

16

Modify feature settings where the context is a sensor setting with a context that reference a specific domain.

To be allowed to actually create, modify or delete a feature setting the user also needs modify sensor settings permission on feature type the setting context references (via the sensor type reference in the context).

Set used classification (5)

5

If granted the classification that is used for a specific classification type in this domain can be defined.

To be allowed to actually set the used classification for a specific classification type, the user also needs modify feature settings permission on one of the the feature types classification type belongs to.

Manage cross sections (17)

17

Permission to create, modify and delete cross sections that are member of a specific domain.

Manage feature creation templates (18)

18

Permission to create, modify and delete Feature Creation Templates that are member of a specific domain.

Manage Map file sets (19)

19

Permission to create, modify and delete Map File Sets that are member of a specific domain.

Manage import definitions (20)

20

Permission to create, modify and delete Stored Import Definitions that are member of a specific domain.

Manage export definitions (21)

21

Permission to create, modify and delete Stored Export Definitions that are member of a specific domain.

Table 3; Permissions on on domains that effect indirect privilege objects. For the permissions listed here to take effect the appropriate feature type permission has to be granted also.


Feature privileges & permissions

Last edited: 11/8/2017 9:27:32 AM

Feature privileges i.e. privileges that have a feature as privilege object define permissions users have on a specific feature. The effective permission a user or user group has on a feature may also include permissions that are transformed from view permissions (of all views the feature is member of and all of their parent views) or inherited from the container permission the feature belongs to.

Using feature privileges allows extremely fine grained access control (on a per feature basis). While this might be useful in many cases, a more effective and dynamic way of controlling access to features is defining view privileges with permissions that are transformed to feature permissions for all members of the view.

Table 1 lists the permissions that are available when defining feature privileges

Permission

No

Description, Actual actions granted

Read (0)

0

If this permission is given the user can read the data of the feature (base data, type specific data, location data, relations, configuration data, ...). This does not imply read permissions on the observations of the feature.

Modify (1)

1

If this permission is given the user can modify the data of the feature excluding configuration data. Modification includes deletion of the feature itself, setting of the editing status of the feature, and starting of approval workflows. Modify permission does not include the permission to modify observation results.

Note that even if this permission is granted to a user a feature is protected against modification if it is in editing status ready.

Comment (2)

2

If this permission is given the user can write comments for a feature

Read observations (3)

3

If this permission is given the user can read the observations of a feature.

Modify observations (4)

4

If this permission is given the user can modify observation of the feature. This includes deletion of observations

Note that even if this permission is granted to a user an observation is protected against modification if it is in editing status ready.

Comment Observations (5)

5

If this permission is given the user can write comments for a feature's observations.

Observation monitoring (6)

6

If this permission is given the user can create observation monitoring definitions on that feature.

Manage (7)

7

The manage feature permission is kind of an elevated modify permission. Following data changes and functions are protected by this permission:

·Delete alarms

·Delete comments (on feature and observation, even if comment was issued by other user)

Modify privileges (8)

8

If this permission is granted the privileges on the feature can be modified. Still the modifying user can only modify feature privileges (add or remove) with a permission that the modifying user is granted himself.

Manage approval workflows (9)

9

If this permission is granted the user can abort and obsolete approval work flows applied to this feature or to observations of this feature.

Set approval obsolete (10)

10

Setting started approval work flows to obsolete.

Table 1: Permissions that can be granted to feature privilege objects

The permission to read the base data of features is the list permission. This permission is either granted by defining a privilege on a view with permission List features (2) or automatically granted by the system if a user has read permissions on a feature that relates to this feature.

If a feature is member of a platform it also inherits all privileges of that platform feature. Note that the platform relation is the only feature relation that will populate privileges to all related features.

A user creating a feature will be automatically granted the permission Read (0) on that feature.This behavior can be disabled with the instance configuration file.


Feature type privileges & permissions

Last edited: 3/30/2018 10:23:12 AM

Feature type privileges i.e. privileges that have a feature type as privilege object, define permissions users have on a specific feature type. The effective permissions a user has on a feature type cannot be inherited from another privilege object and cannot be transformed from another permission on another privilege object.

There are several indirect privilege objects that are referenced to specific feature types and to domains. The permission for accessing these objects is granted if the permission is granted on the feature type as well as on the domain. This allows you to assign permissions in a very flexible way.

Example: If you grant the permission to modify a classification that is used by a specific feature type this does not allow the privilege subject to modify any classification. Only if the same permission is also granted on a domain the privilege subject has the permission to modify classifications belonging to that feature type in that domain.

Table 1 lists the feature type permissions.

Permission | No | Description, Actual actions granted
Modify sensors (1) | 1 | Permission to create, modify and delete sensors that are of a sensor type which is linked to that feature type. To be allowed to actually create, modify or delete a sensor the user also needs modify sensors permission on the domain the sensor belongs to (or a parent domain)
Modify classifications (2) | 2 | Permission to create modify and delete classifications that are of a classification type which is used by that feature type. To be allowed to actually create, modify or delete a classification the user also needs modify classifications permission on the domain the classifications belongs to (or a parent domain).
Modify feature subtypes (3) | 3 | Permission to create modify and delete feature subtypes. To be allowed to actually create, modify or delete a feature subtype the user also needs modify feature subtypes permission on the domain the subtype belongs to (or a parent domain).
Modify feature settings (4) | 4 | Modify feature settings where the context is a feature setting with a context that reference this feature type. To be allowed to actually create, modify or delete a feature setting the user also needs modify feature settings permission on the domain the context references.
Modify sensor settings (5) | 5 | Modify sensor settings where the context is a sensor of a type that is referenced to that feature type. To be allowed to actually create, modify or delete a sensor setting the user also needs modify sensor settings permission on the domain the context references.
Create features (6) | 6 | If granted the privilege subject can create features of this type. To be allowed to actually create, features in a domain the user also needs the on the domain the context references.

Table 1: Permissions on feature types


View privileges & permissions

Last edited: 11/8/2017 9:27:44 AM

View privileges i.e. privileges that have a view as privilege object define permissions users have on a specific view. The effective permissions a user has on a specific view can be inherited from all parent views of that view, the system permission All permissions on root views is transformed into all available view permissions on all root views.

Note that only public views can be privilege objects, i.e. you cannot define privileges on private views. Private views inherit privileges from their parent view.

View privileges can not only be used to grant access to the views itself but also to the member features of the view (via transformed permissions). Granting permissions on features through view privileges is an extremely flexible and dynamic way to control access to features. When defining access to features by using view privileges you should mind following points:

·Since the members of views are determined by queries and features are not directly linked to views the permissions granted for features through view privileges can change whenever data of a feature changes. E.g. if you define a view that contains all features having an observation count greater 100 the view members might change when new observations are added to features. If that view defines privileges for accessing features those privileges will be granted to new members of the view automatically or removed from views that are not member any more.

·One feature can be member of any number of views and therefore the effect permissions a specific user has on a feature might include transformed permissions from several views.

·Privileges defined on views are inherited by all subordinate views of that view (on any level) I.e. the permissions granted through a privilege with parent view as privilege object will automatically be granted to all subordinate views. Therefore you can use view structure to further ease the work of defining privileges.

Table 1 and 2 list the permissions that are available when defining privileges that have a view as privilege object. Wile table 1 lists features that are effective on the view itself table 2 lists the permissions that are granted for views but are transformed to feature permissions for all members of a view.

Since some view permissions are transformed into feature permissions for all contained features and since the view members are cached it can happen that changes to view permissions that affect its members take some time to be effective.

Permission

No

Description

Modify view (0)

0

If this permission is given the user can rename a view change the view's filter conditions, change the view's presentation options etc.

This permission also includes the permission to delete a view and to change the permissions on the view.

List features (2)

2

If this permission granted the member features of of the view can be listed. Listing features allows reading the feature's identification data only, it does not implicitly give full read rights to all the features of the view.

If this permission is defined in a privilege for a view it is propagated to all subordinate views of that view.

List views (3)

3

If this permission is granted, user can list the subordinate views of the view and can read the view definition.

For a user to be able to list a root view this permission has to be granted on that root view.

Modify view privileges (4)

4

If granted the privilege subject can modify the privileges on that view. However the privilege subject can only add or remove privileges that it is granted itself.

Modify subordinate views (5)

5

This permission will be transformed to the Modify view (0) permission on all subordinate views. By itself this permission has not effect.

Table 1: Permissions that can be granted to view privilege objects

Permission | No | Description
Read features (100) | 100 | Same as the feature permission Read but applies to all features that are member of this view
Modify features (101) | 101 | Same as the feature permission Modify but applies to all features that are member of this view
Comment features (102) | 102 | Same as the feature permission Comment but applies to all features that are member of this view
Read observations (103) | 103 | Same as the feature permission Read observations but applies to all features that are member of this view
Modify observations (104) | 104 | Same as the feature permission Modify observations but applies to all features that are member of this view
Comment observations (105) | 105 | Same as the feature permission Comment observations but applies to all features that are member of this view
Observation Monitoring (106) | 106 | If this permission is given the user can create observation monitoring definitions on that feature.
Manage features (107) | 107 | Same as the feature permission Manage but applies to all features that are member of this view
Modify feature privileges (108) | 108 | If this permission is granted the privileges on the feature can be modified. Still the modifying user can only modify feature privileges (add or remove) with a permission that the modifying user is granted himself.
Abort approval workflows (109) | 109 | Same as the feature permission Manage approval workflows but applies to all features that are member of this view
Set approvals obsolete (110) | 110 | Setting started approval work flows to obsolete.

Table 1: Permissions that can be granted to view privilege objects and are transformed to permissions on all member features.


User sessions

Last edited: 10/5/2017 11:51:44 AM

When a user interacts with the Application Server using a client application as the Smart Client he does so in the context of a user session. A user session is created during the login process.

A single user can have more than one user session at one time (e.g. when accessing the system from different clients). User sessions can be open or closed, only open user sessions can be used to access the Application server, closed user sessions are kept on the Application Server for traceability reasons only. Every request to the Application Server (except requests needed during login and some general information gathering requests) must refer to an open user session to be answered by the Application Server.

Open user sessions can be in different states according to time stamp when they were last used for a request to the Application Server. See chapter User session expiration for more details

All open user sessions will be closed when the Application Server restarts. If the Application Server is not shut down cleanly (e.g. due to a power shortage) user sessions that still seem to be open on startup of the Application Server will be closed at that point in time.

The Application Server records several parameters for each user session. See table 2 for detaile

Logged datum

Description

Session ID

Each user session gets a unique numerical ID.

Session user

The system user that is linked to this session.

Session token

Unique identifier for the session. The system uses a Global Unique Identifier (GUID). This token is subsequently used for connecting requests to the application server with a specific user session.

Session start

Timestamp when the session was created

Session end

Timestamp when the session was closed (written when a session is closed).

Session end reason

The reason why a session was ended. Can be one of the following reasons:

·User request: User or user's client software requested the logout from the Application Server.

·Session timeout: The user session's maximum idle time was exceeded and the session was therefore closed

·Forced session close: A user session was forcefully closed by another user.

·Server restart: A user session was opened when the Application Server was shut down. On restart the server cleans the user sessions still marked as open.

·Unknown: Session was closed due to an unknown reason

Session last used

Timestamp when the session was last used for querying the Application Server. This timestamp updated in memory whenever a client requests something from the Application Server. On closing of the session the value is persisted.

Client information

Additional information that can be provided by the client:

·Client name: String that identifies the client software

·Version: Version of the client software

Time offset

The time offset of the client given relative to UTC in minutes. This is used to compute date time values according to the clients time offset.

Allowed session idle time

The time (in seconds) that the session is allowed to be idle, before it is considered an expired session.

Authentication attempt ID

The authentication attempt that was used when a user session was created.

Table 1: Details logged for each user session


Preconditions for user session creation

Last edited: 10/5/2017 11:51:32 AM

The creation of a user session is done during login. Before a session can be created the systems checks all preconditions listed in Table 1. If one of these preconditions is not met the system will not create a user session, the login attempt will fail and the client will be informed accordingly.

Precondition | Description
User is authenticated | Before a session is created the user has to be authenticated, only one session can be created for one successful authentication attempt.
User is not locked | A user session cannot be created if the user account is locked due to repeated authentication failures. The user account can be unlocked by users with the system permission Manage users and user groups (0).
User is active | No user session can be created if the user account is set inactive. A user with the system permission Manage users and user groups (0) system can set a user inactive or active.
Current date and time is within the user's validity time span | Each user account can have a validity time span. Creating a user session is only possible if the current date is within that validity time span, or if no validity time span is set.
User's password is not expired | A user can still authenticate with an expired password but no session can be created. See password aging for details.
Application Server is not closed | The Application Server must be configured to allow new user sessions. If the server does not allow new user sessions only users having the system permission Create user session when server is closed (13) can create new user sessions.

Table 1: Precondition that have to be met before a user session can be created.


Login, Logout

Last edited: 10/5/2017 11:51:28 AM

Before a user can work with the Application Server he has to perform a login process. This process consists of authenticating against the system and creating a new user session. Login is only successful if the authentication was successful and a session could be created.

After a user ended work with the system he should log out of the Application Server. When logging out the user closes the user session he created during login.


Closing user sessions

Last edited: 11/8/2017 9:27:20 AM

Closing of a session can be triggered by several different events. As soon as a session is closed any requests to the Application Server with the session token of the closed session will fail. Whenever a session is closed the system writes the Session end date to the session. Note that this Session end date does not necessarily mean that the user who initiated that session stopped working at that point in time.

The session closing trigger will be remembered in the user session log.

Session closing trigger | Notes
User's request | If the user intentionally logs out from the Application Server and therefore closes his own session
Forcefully closed | A user with the system permission Close user sessions (3) closed the sessions of another user.
System start up | On start up of the Application Server all sessions still marked as open are closed with this state. While usually all open sessions are closed on shutdown of the Application Server there might still be open sessions on start up if the server could not finalize all shutdown actions cleanly.
System shut down | On shutdown of the Application Sever all open session are closed with this stat.
Idling | When a new user session shall be created but the license does not allow any more concurrent connection, the Application Server automatically closes the session that has bee idling for the longest time.
Abandoned | Before creation of a new user session all abandoned user sessions are closed with this state.
Server update | When the server performs a data update all open sessions of users who do not have the system permission Create user session when server is closed (13) will be closed with this state.

Table 1: Events that trigger the closing of sessions


User session expiration

Last edited: 10/5/2017 11:51:40 AM

The Application Server cannot trust that all user sessions are closed by a log out. Clients might just forget to log out, might crash, loose internet connection etc. To still keep a valid record of open user sessions the Application Server implements a mechanism for session expiration. This mechanism is also important since your license might restrict the number of concurrent user sessions, Clients that fail or forget to log out would use up your allowed number of concurrent connections quickly.

Depending on how long ago the a user session was last used to query the Application Server the session is classified into different states. Table one lists these states and their meaning. When the Application Server receives the request to create a new user session the state of existing user sessions will be evaluated and idle or abandoned sessions might be closed, according to the logic described below.

State

Meaning

Active

A session is active if it was used for a request to the Application Server within the session idle time span negotiated between Client and Server.

Idle

A session is considered idle if it was not used for a request to the Application Server within the session idled time span negotiated between Client and Server but if the user session was used within the time span specified with the global setting User session abandoned threshold

Idle user sessions might be closed by the Application Server if another user requests a new user session but the license does not allow more concurrent user sessions.

Abandoned

A session is considered as abandoned if it was not used within the time span specified in the global settings.

Abandoned user sessions will be closed by the Application Server automatically.

Table 1: States for open user sessions

When a user tries to create a new user session (during login) the Application Server first closes all abandoned sessions. Then the Application Server counts the number of sessions in active or idle state and if this number is less than the allowed number of concurrent connections specified by the currently installed license the user session can be created (if all other conditions for session creation are met, see chapter Preconditions for user session creation for details).

If the Application Server detects that the currently installed license does not allow the creation of another (concurrent) user session it will automatically close the the user session that has been idle for the longest time. If there are no idle user sessions the Application Server will not create a new user session.

Each user session stores the timestamp when it was last used and the time span it is allowed to be idle. The time a session is allowed to be idle is given in seconds and defaults to the value of the global setting User sessions & security: Default User session timeout [s] when the session is created. However the client can negotiate another timeout value somewhere between 300 seconds and the value defined by the global setting User sessions & security: Maximum allowed user session timeout [s]. If the client tries to set a longer idle time it will be set to User sessions & security: Maximum allowed user session timeout [s] automatically. If the client tries to set a shorter allowed idle time, the idle time will be set to 300 seconds.

Changing the global setting User sessions & security: Default User session timeout [s] and User sessions & security: Maximum allowed user session timeout [s] will only affect sessions created thereafter.


Concurrent user sessions and licensing

Last edited: 10/5/2017 11:51:10 AM

As explained in chapter User session expiration the Application Server implements a logic that automatically closes idle or abandoned sessions whenever a new user session is created. User sessions considered as active are never closed by the Application Server. Therefore global settings User sessions & security: Default User session timeout [s] and User sessions & security: Maximum allowed user session timeout [s] will influence if new user sessions can be created especially when you have many users and a low limit for allowed concurrent connections.

If the idling threshold for user sessions is high the Application Server the user sessions will be considered as active even if the user did not actively request data from the Application Server for a long time.


User session log

Last edited: 10/5/2017 11:51:44 AM

For traceability reasons data about all user sessions (open and closed) is stored permanently by the Application Server. If the user has no special permission he can only list his own user sessions. Users with the system permission Read all user sessions can also list sessions of other users.

Since the session log might get huge over time the Application Server provides the possibility to purge the user session log. Purging will delete all closed sessions from the session log that were closed before a given timestamp. Purging the session log can be triggered by users with the system permission Purge user session log (18).


Preventing new user sessions

Last edited: 10/5/2017 11:51:10 AM

You can prevent the creation of new user sessions while keeping the already started user sessions untouched. This is especially useful if you plan to shutdown your server in the near future and if you do not want to close the sessions of already connected users abruptly.

Preventing the creation of new user sessions is done by setting the global setting User sessions & security: Allow new user sessions to false. If this setting false the Application Server will prevent new sessions from being created, except if the user who wants to create the session has the system permission Create user session when server is closed (13). Currently active sessions will not be affected.


User management

Last edited: 11/8/2017 9:24:02 AM

Users and user groups are the basis for authentication, authorization, user specific settings and other things more. User management is the task of creating and modifying users and user groups.


User

Last edited: 11/8/2017 9:24:06 AM

A user is the stored representation of a person or process accessing the system. A user is identified in the system by its username, this name must be unique within the system.

While it can of course not be checked by the Application Server if every user maps to exactly one natural person or one process we strongly recommend to keep it that way. Using the same (system) user for different persons or processes is a risk for information security. Even in a small installation scenario, even if you start with only a few (natural) users accessing the system always map natural persons or processes to their dedicated Redbex users.

Because of our recommendation to map natural users one to one to system users this manual does not distinguish between the natural person accessing the system and it's the system representation both are simply called user. The system stores various data for each user to support authentication, session creation, communication and other things more. Table 1 shows and explains the basic data stored with user.

Property

Description

Active

Only active users can login to the system. This flag can be used to disable accounts that are no longer used. Note that users who created data in the Redbex System can usually not be deleted any more, use this Active flag instead of deleting a user.

Address

The postal address of the user

Application Server Culture

Define number formats, date formats and other culture specific characteristics that are used when the user interacts with the Application Server.

The language that is used by the Application Server when communicating with the Smart Client is also detected from this setting. The Application Server will use the language that fits the selected culture, or will use English if that language is not one of the supported Application Server Languages.

Authentication type

Defines how authentication will be performed for this user account.

For more details see chapter Authentication.

Company

The company a user belongs to.

Department

Department the user belongs to.

Description

Can be used to add any other information to the user.

Email address

Address of the user's email account.

This email address will be used whenever the system sends out information to a user via email (e.g. in Messaging). A valid email address is required for each user since the system will send important information to the user via email.

The validity of an email address is checked by the Application Server using following regular expression (case insensitive match):

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

First, middle and last name

We recommend to store this information with every user. If the user is not a referring to a natural person we recommend leave all of these fields empty.

Focus domain

Defines the default focus domain. This setting provides the possibility to set the Focus domain for users. However it is up to the used client how this Focus Domain is used.

Gender

Gender of the user.

Used by the system when addressing the user in emails etc.

Locked

Locked users cannot login to the system. Users are automatically locked if too many failed login authentication attempts are recorded in a short time period.

Evaluated during creation of user sessions.

Mobile phone number

Number of the user's mobile phone.

This phone number will be used if the system sends out information to a user via SMS (for details see chapter Messaging).

Whenever this number is changed, Redbex will validate and reformat the provided number to get an internationally valid presentation of that number. See also Global Setting Default region for phone numbers.

Password

Authentication data, see Authentication for more details.

Password expiration date

Date when the currently set password will expire, if undefined the password will never expire

Phone number

The phone number of the user.

Whenever this number is changed, Redbex will validate and reformat the provided number to get an internationally valid presentation of that number. See also Global Setting Default region for phone numbers.

Picture

A picture of the user. The Application Server will automatically re-size the picture (proportionally) to a maximum size of 400 x 400 pixel.

Position

The position of the user within the company.

Post-nominal letters

Post-nominal letters are letters placed after the name of a person to indicate that the individual holds a position, educational degree, accreditation, office, or honor. E.g. MSc.

Pre-nominal letters

Pre-nominal letters are a title which is placed before the name of a person, e.g. Dr.

Publish extended information

This setting defines which user data is visible to all users of the system. See Table 3 for details.

User ID

Unique identification number for the user. Assigned by the system when the user is created.

Internally Redbex identifies users with this ID, it is therefore possible to change the user name at any time.

User name

Unique name of the user. This name is used to login to the system. The user name can consist of any Unicode characters except control characters (tab, line feed etc).

A user name can not start or end with a blank space characters but can include blank space characters.

Validity time span Valid From - Valid To

Users can be configured to be valid only in a specific time span, users can only login if the current date time is within this validity time span.

Set Valid from and Valid to to null to disable lower and/or upper validity range limits.

Table 1: Data stored for each user

Properties of a user can be modified by the user himself or by other users with the System Permission Manage users and user groups (0). Table 2 shows which properties can be changed by whom. Not all properties are readable for all users, Table 3 shows which properties can be read by whom.

Property | User himself | Users with user management system permission
Active |  |
Address |  |
Application Server Culture |  |
Authentication type |  |
Company |  |
Description |  |
Email address |  |
First, middle and last name |  |
Focus domain |  |
Gender |  |
Locked |  |
Mobile phone number |  |
Password | Cannot be modified directly, will be modified when the user changes his password | Can only reset to a random password
Password expiration date |  |
Phone number |  |
Picture |  |
Position |  |
Post-nominal letters | Cannot be modified directly, will be modified when the user changes his password | Can only reset to a random password
Pre-nominal letters |  |
Publish extended information |  |
User ID |  |
User name |  |
Validity time span Valid From - Valid To |  |

Table 2: User data that can be changed by the user himself or by users with the Manage users and user groups (0) system permission

Some basic data stored for each user is readable for every other user in the system. Extended information about a user can be published by the user himself by setting the publish extended information configuration. Table 3 shows which user data is visible to whom.

Property | User himself and users with user management system permission | All users
Active |  | if published by user
Address |  |
Application Server Culture |  |
Authentication type |  |
Company |  |
Description |  |
Email address |  |
First, middle and last name |  |
Focus domain |  |
Gender |  |
Locked |  |
Mobile phone number |  |
Password |  |
Password expiration date |  |
Phone number |  | if published by user
Picture |  | if published by user
Position |  | if published by user
Post-nominal letters |  | if published by user
Pre-nominal letters |  |
Publish extended information |  |
User ID |  |
User name |  |
Validity time span Valid From - Valid To |  |

Table 3: Visibility of user data


Setting a users password

Last edited: 11/8/2017 9:24:12 AM

For a user to be able to connect to the Application Server he needs a user name and a password. The user name is defined when a user is created (and can also be changed afterwards).

For users with Authentication type Local

Users with the system permission Manage users and user groups (0) can advice the Application Server to set or reset the password of a user, if the authentication type for that user is set to local.

The Application Server will then assign a new random password to the specified user that matches the password quality rules defined in the Global Settings. The new password will be sent via email to the email address associated with that user. The Email will contain all information the user needs to logon to the Application Server.

After the Application Server set or reset the password of a user it will force the user to change his password on the next (or first) login.

Note that there is no way for the user who initiates resetting a password to know the new password of the user.


User groups

Last edited: 11/8/2017 9:24:20 AM

A user group is a named set of users. A user that is in this set of users is assigned to that group. One user can be assigned in any number of user groups. A user group can have any number of users assigned.

User groups can be structured tree-like in groups and subgroups. There is no system limit on the depth of that groups-tree. If a user is assigned to a subgroup he is implicitly member of all groups above and including that group in the group hierarchy. Figure 1 and 2 show an example of the membership propagation. Figure 1 shows the user to user group assignment as defined, figure 2 shows the effective user group membership.

The name of a user group must be unique within the hierarchy level of the user group, therefore the fully qualified name of the user group (it's path from the root group) is always unique. User groups can only be created and modified (including adding members to the group) by users with the system permission Manage users and user groups (0).

Figure 1: Example of membership propagation. The first image shows the group assignment, the second the second the actual memberships.


Manager user

Last edited: 11/8/2017 9:27:28 AM

In Redbex there is no special almighty administrator user nor is there an administrator permission that could be assigned to users. If you want an almighty user i.e. someone who is allowed to access every resource in the system you have to define a user with the appropriate privileges yourself. While this concept sometimes results a little bit more work when configuring privileges it gives you much more control on who can access what in the system. For example it is possible to define privileges in a way that a specific user has all the permission to configure the system, but still has no access on the content itself.

During Installation of the Application Server Database the Setup Program will create a manager user (with a user name and password you choose) that will be granted all necessary permissions to configure the system, these are:

·All System permissions

·All Domain permissions on the root domain.

If in later versions of the Application Server new permissions are added this user will also automatically get these new permissions.

The manager user created by the installer cannot be deleted and cannot be deactivated.

We recommend to use the manager user only for administrative purposes.


Synchronization with Active Directory

Last edited: 11/8/2017 9:24:38 AM

Redbex allows synchronizing users with the members of a specified Active Directory user group. If you plan to use Active Directory Authentication this will allow you to automatically give all users of that Active Directory user group access to the Redbex system.

To enable this functionality, the global settings under Active Directory group must be set.

Active directory synchronization can be manually triggered from the used client software or can be automated using the Active Directory Synchronization job type.

For the actual synchronization of users the Application Server will try to access the Active Directory Lightweight Directory Services (ADLDS) and will look up the members of the specified user group. For accessing ADLDS the Application Server will either use LDAP or LDAPS protocol, depending on your Global Settings.

For all Active Directory users in the specified Active Directory user group that are not locked and have a valid e-mail address set the Application Server will check if there is a Redbex user account with the same user name.

·If no, a new Redbex user account with that name will be created. All properties of the newly created account will be set to the properties found for the Active directory user. The authentication type for the newly created Redbex account will be set to Active directory

·If yes, all properties of the existing Redbex users will be modified to match the properties in the Active Directory. The Redbex user's authentication type will be set to Active directory.

If the Global setting Keep Local is not set all Redbex user accounts where no corresponding Active Directory group member can be found will be deactivated. If you want to work with a mixture of different authentication types (Active Directory and local) you shall therefore set the Global setting Keep Local to true.

The Manager account created during installation of the Redbex Application Server Database will never be deactivated by the synchronization irrespective of the Keep Local setting.

Synchronized information

When creating new Redbex users from an Active Directory user, or when updating existing users Redbex will automatically fill in the following data with the equivalent properties of the Active Directory user account.

·Username

·E-mail

·First name

·Middle name

·Last name

·Pre-nominal letters

·Description

·Phone number

·Cell phone number

·Address

·Company

·Department

·Position

Redbex will also set the following properties for users created during the synchronization process:

·Gender: Will be set to Undefined

·Authentication type: Will be set to Active Directory depending on the option with which synchronization is taking place

·Culture: Will be set to the culture of the user who performs the synchronization

·Publish extended information: Will be set to false


%Text%

Navigation: Application Server > Common services >

Feature search

Last edited: 11/8/2017 9:27:20 AM

The Application Server provides the possibility to quickly search for features. Table 1 list the search criteria that can be combined. A search can be performed with any combination of these criteria but at least one of these criteria has to be defined.

Criteria | Description
Domains | A list of domains that shall be searched. If given the search is restricted to features of these domains only. If not given features in all domains will be searched.
Feature types | A list of feature types to be searched. If given the search is restricted to features of these types. If not given features of any feature type will be searched.
Feature subtype | A simple wildcard string that limits the search to features with matching subtype names only. If not given features of any subtype will be searched.
Feature name | A simple wildcard string that is matched against feature names.

Table 1: Criteria that can be used in feature search

No matter how many features match the search criteria the search will return a maximum of 100 features. If a search results in more than 100 matches the server will inform the user about this fact but still will only return the first 100 features.

To be able to use the Feature Search a user must have the System Permission List all Features (27).


Event schedules

Last edited: 10/25/2017 8:04:08 AM

An event schedule defines points in time when a specific action shall be triggered. Event schedules are used in different parts of the Application Server. For example stored job definitions can define event schedules that specify when a job shall be triggered from a stored job definition.

An Event Schedule consist of event definitions for discrete and recurring events. Discrete event definitions are user defined date&time values that define when and event shall be triggered. Recurring events definitions do not define discrete date&time values but define a scheme for regularly repeated events. The actual points in time when the event schedule triggers events are calculated by evaluating the recurring event definition and adding the discrete events.

Event schedules are precise to the minute, i.e. you can schedule events with a maximum precision of a minute. However the actual execution of the action associated with an event schedule might be delayed (e.g. depending on the system load).

Each event schedule is defined in a specific Time zone, i.e. all data & time values used in the definition of an event schedule are taken as date & time values in that time zone. The same Application Server can handle Event Schedules using Different Time zones.

An Event Schedule can be active or inactive. By deactivating an Event Schedule you can prevent triggering of actions while leaving the definition itself untouched.


Discrete events

Last edited: 10/23/2017 8:11:48 AM

A event schedule can define discrete points in time when the action the schedule was created for shall be triggered. Each event schedule can define any number these discrete points in time.

The discrete points in time are taken as points in time in the Time zone set for the Event Schedule.


Recurring events

Last edited: 10/5/2017 11:51:34 AM

An event schedule can define recurring events, that are used to trigger actions repeatedly without the need to specify the exact date and time for each of these points in time.

The definition of the recurring events is done using repetition schemes and is similar to the way you schedule jobs with the Cron scheduler common on Unix-like operating systems.

A repetition scheme consists of five fields minutes of hour, hours of day, days of month, months of year, and days of week. Each of these fields can hold a comma separated list of alphanumeric definitions as described in table 1. The definitions for one filed are put together with a logical OR, therefore the sequence of definitions in a field not relevant.

A recurring event is due at a specific point in time if at least one of the expressions in each of these five fields match that specific point in time.

The definition for recurring events in an event schedule can optionally have a start date and an end date that define the validity time span of the recurring event definition. Table 3 shows the effects of setting these boundary values.

Expressions in repetition scheme fields

Single wildcard expression. A single wildcard (*), which covers all values for the field. So a * in days of month means all days of a month (which varies with month and year). If present, a single wildcard expression must be the only expression for a field.

Single Numeric expression. A single numeric value, e.g. 5. Naturally, the set of values that are valid for each field varies. See table 2 for details

Numeric range expression. A numeric range where the minimum and maximum are separated by a dash, e.g. 1-10. You can also specify these in the wrong order and they will be fixed. So 10-5 will be treated as 5-10. Numeric ranges will be expanded to all integer values in that range. E.g. 5-10 expands to 5,6,7,8,9,10

Wildcard with modulo expression. E.g. */4. This means every possible value in that field that has a remainder o zero when divided by 4.

Example */6 in the hours of day field will match 00:00, 06:00, 12:00, 18:00

Numeric range with modulo expression. E.g. 1-10/2 will result in 2,4,6,8,10

Table 1: expressions that can be used in a repetition scheme field

Field | Range | Notes
Minutes | 0-59 |
Hours | 0-23 |
Days | 1-31 |
Months | 1-12 |
Days Of Week | 0-6 | Sunday = 0, Monday = 1 etc.

Table 2: Valid values for each field of a repetition scheme

Start date | End date | Description
not given | not given | Start date and end date do not constrain job triggering.
given | not given | Job will be triggered if triggering time stamp equal or greater than the given start date.
not given | given | Job will be triggered if triggering time stamp is equal or before given end date.
given | given | Job will be triggered if triggering time stamp is between given start date and given end date, which includes time stamps that are equal start date or end date.

Table 3: Effect of specification of start and end date

Examples

Table 3 lists some examples of repetition schemes and how they would interpreted as a recurring schedule.

Min | Hours | Days | Months | Days of Week | Description
* | * | * | * | * | This pattern causes a task to be launched every minute.
5 | * | * | * | * | This pattern causes a task to be launched once every hour, at the fifth minute of the hour (00:05, 01:05, 02:05 etc.).
0 | 0 | 1 | * | * | This pattern causes a task to be on the first of each month at 00:00
12 | 30 | 1-7 | * | 1 | This pattern causes a task to be on the first Monday of each month at 12:30
* | 12 | * | * | 1 | This pattern causes a task to be launched every minute during the 12th hour of Monday.
* | 12 | 16 | * | 1 | This pattern causes a task to be launched every minute during the 12th hour of Monday, 16th, but only if the day is the 16th of the month.
59 | 11 | * | * | 1,2,3,4,5 | This pattern causes a task to be launched at 11:59AM on Monday, Tuesday, Wednesday, Thursday and Friday.
59 | 11 | * | * | 1-5 | This pattern is equivalent to the previous one.
*/15 | 9-17 | * | * | * | This pattern causes a task to be launched every 15 minutes between the 9th and 17th hour of the day (9:00, 9:15, 9:30, 9:45 and so on... note that the last execution will be at 17:45). The slash character can be used to identify periodic values, in the form of a/b.
* | 12 | 10-16/2 | * | * | This pattern causes a task to be launched every minute during the 12th hour of the day, but only if the day is the 10th, the 12th, the 14th or the16th of the month.
* | 12 | 1-15,17,20-25 | * | * | This pattern causes a task to be launched every minute during the 12th hour of the day, but the day of the month must be between the 1st and the 15th, the 20th and the 25, or at least it must be the 17th.

Table 4: Examples of repetition schemes


Pauses for recurring events

Last edited: 10/5/2017 11:51:36 AM

An Event Schedule can define pauses for recurring events. Pauses are time intervals in which no actions will be be triggered from the recurring event definition.

Any number of Recurring Event Pauses can be defined for a single Event Schedule. The Time Interval specified with an a pause is a half closed interval [Pause start, Pause End). I.e. actions planned exactly at the start point of the Pause will be be executed, actions planned exactly at the end of the interval will not be executed.


Testing schedules

Last edited: 10/5/2017 11:51:44 AM

The Application Server provides the possibilitiy to test a defined event schedule. Testing an event schedule will return a list of timestamps that represent points in time when the events would trigger an action.


%Text%

Navigation: Application Server > Common services >

Jobs

Last edited: 10/5/2017 11:51:26 AM

Jobs are processes the server runs asynchronously in the background to perform time consuming, performance demanding or regular tasks. E.g. execution of calculated features, import/export of data from external systems or files, internal system functions like the management of system caches and others more.

The Application Server predefines job types that can be configured by the user by setting execution parameters for a job. An example of a job type is the execution of a calculated feature. In this case the feature would be an execution parameter of the job.

Jobs can be triggered by the system itself, by a user via stored jobs definitions, by observation monitoring events, by other jobs or by manual user interaction. The execution of triggered jobs is handled by the job engine - a queuing and load balancing mechanism that allows to regulate the performance impact of jobs on the overall system.

The user either implicitly or explicitly creates a job definition that holds all information necessary for the Application Server to perform a specific job. That job definition is then passed to the job engine.


Job states

Last edited: 10/5/2017 11:51:26 AM

Throughout its lifetime a job can be in several job states. Table 1 lists the states a job can be in along with a description, figure 1 shows the states along with the transitions between them.

Jobs with status running, being paused and paused provide additional progress information. Note that only the jobs in status running are actually processed by the system i.e use processing power. The job states are divided in two groups the active states and the archive states. Jobs with active state are not yet executed or are currently executed, jobs in archive states were either already executed or terminated before or during execution.

 | Status | Description
Active states | Pending | The job has been triggered but is still waiting for execution.
 | Running | The job is currently being executed, i.e. there is a thread that processes the job on the operating system.
 | Being paused | Somebody requested the job that was already in running state to be paused. The job's thread might still be active (i.e. consuming system resources) but it will be paused at the next possibility.
 | Paused | The job was paused and the job's thread is inactive i.e. not consuming system resources
Archive states | Closed without execution | A job that was queued but was closed by a user before it was executed.
 | Finished | Job was executed and finished execution. Note this does not necessarily mean that the job itself was executed successfully.
 | Not triggered by predecessor | The job was queued as a successor of another job - its predecessor. This predecessor did not trigger successor jobs.
 | Aborted | A job was already in running state when a user stopped the execution of the job.
 | Closed without execution at system shutdown | Jobs in pending state are automatically put to this status when the system shuts down.
 | Aborted at system shutdown | Jobs that are executed at the time of system shutdown will be put into this state.

Table 1: States a job can be in

Figure 1: State a job can be in and transitions between status.


Impersonation

Last edited: 10/5/2017 11:51:26 AM

A job even if triggered by the by the job scheduler or some other event is always associated with a user - this user is called the job owner. When the job is triggered the system runs this job with the privileges of the job owner, even though this user does not necessarily have an active session at that point in time. The job engine is therefore impersonates the job owner when it executes a job. If the job owner does not have the system permission Create and modify jobs the job will not be executed.

Jobs that the system itself (e.g. cache clearing) run as a special user called system.


Load balancing

Last edited: 10/5/2017 11:51:26 AM

Since jobs can be time consuming and performance demanding, the Application Server implements a queuing an load balancing mechanism for jobs. This allows to control the performance implication the execution of jobs has on the system.

Every job has an execution priority that may be any integer between 0 and 5 where 0 stands for the highest priority, 5 for the lowest, all priorities have alias names as listed in table 1. Not all priorities can be used by all users, see table 1 for details. All jobs are initially put to the job queue and therefore put into pending state i.e. they are not immediately executed but they wait for execution. The system decides which jobs are executed next based on the execution priority of the job. Jobs with higher priority are executed before jobs with lower priority. Among jobs with the same priority older jobs (jobs that have been in pending state for a longer time) are executed before newer jobs.

Execution Priority | Name of execution priority | Description
0 1 2 | Privileged high Privileged medium Privilege low | Reserved for users with the system permission Use privileged job priorities (16)
3 4 5 | Unprivileged high Unprivileged medium Unprivileged low | Can be used by any user

Table 1: Summary of job execution priorities

To limit the load implication the execution of jobs has on the system the Miscellaneous: Maximum concurrent job count can be configured as global setting. The default value for this setting is 16, the minimum value is 2, the maximum value is 128. Each executed job is executed on a separate thread and may therefore (according to hardware resources available, and according to the operating systems logic) be run on a separate processor.

Whenever a new job is created it is put onto the job queue and the system checks if there are already more than <%GS_MAXIMUMNUMBEROFCONCURRENTJOBS%> jobs running, if not it selects as many jobs on the job queue as possible and starts them. If no more jobs can be started the newly created jobs are left on the queue (and stay in pending state) for later execution. Whenever a running job finishes (and is put into some archive state) the system checks the job queue again and will execute the oldest job with highest priority (if any). Jobs in state being paused/paused are included when counting the number of concurrently running jobs.

Note that due to the prioritization logic described above jobs with higher execution priority will always be handled first, even if the are newer jobs with lower execution priority. In rare cases this can lead to the situation that lower priority jobs are never executed if higher priority jobs are created frequently.

Additionally to the execution priority each job also has a thread scheduling priority that defines how the operating system prioritizes the thread started for a job. Threads in the operating system are scheduled to run based on their scheduling priority. Each thread in the system is assigned a scheduling priority. The operating system treats all threads with the same priority as equal. The system assigns time slices in a round-robin fashion to all threads with the highest priority. If none of these threads are ready to run, the system assigns time slices in a round-robin fashion to all threads with the next highest priority.

If a higher-priority thread becomes available to run, the system ceases to execute the lower-priority thread, and assigns a full time slice to the higher-priority thread, this is called a context switch in the operating system. You can assign the thread scheduling priorities listed in table 2 to jobs. Thread scheduling priorities are supported to optimize performance on installations a high load of jobs, in normal scenarios we recommend to leave the thread scheduling priority untouched, i.e. in priority normal.

Priority | Operating systems handling guideline
Normal | (default) This is the default priority assigned to jobs. The Thread can be scheduled after threads with Above normal priority and before those with Below normal priority.
Below normal | The thread can be scheduled after threads with Normal priority and before those with Lowest priority.
Lowest | The Thread can be scheduled after threads with any other priority.

Table 1: Thread scheduling priorities supported by jobs.


Data stored for jobs

Last edited: 10/5/2017 11:51:26 AM

Each triggered job, in any state is recorded by the system and various data is stored for each job to ensure traceability. Table 1 lists the data stored for each job.

Datum | Description
Job ID | Unique ID of the job created by the system when the job is created
Job type | The type of the job
Execution parameters | The execution parameters that were applied to the job
Owner | The user who owns this job
Status | The status the job is currently in
Last status change | The point in time when the status of the job was last changed.
Triggered at | The point in time when the job was triggered
Executed at | The point in time when the job was first put into running state.
Finished at | The point in time when the job finished its execution
Execution priority | The execution priority of the job
Thread scheduling priority | The thread scheduling priority assigned to the job
Progress | Progress of the job in percent
Job log | Textual information about the processing of the job.
Successor jobs | Successor jobs of this job

Table 1: Data stored by the Application Server for each triggered job


Listing jobs

Last edited: 10/5/2017 11:51:26 AM

The Application Server can list jobs that are either active or archived along with all the stored data of the jobs.

The Application Server can list all jobs that are currently in an active state. Users can list only jobs that they own, or if they have the system permission List all jobs they can list jobs irrespective of their owner. When listing a job the user can see all data that is stored for jobs.

The Application Server can list all jobs that are in an archived state. Users can list only jobs that they own, or if they have the system permission List all jobs (9) they can list jobs irrespective of their. Since there might be huge amounts of jobs in archived state the Application Server allows to list all jobs in archived state of a specific times pan.


Job log

Last edited: 11/8/2017 9:31:16 AM

Whenever a job is executed it creates a log of actions performed. This job log is an action log that is stored along with other job data in the job history. The contents of the job log are defined by the job type. The job log is the main source for getting details about unsuccessful jobs, warnings issued during job execution and other information. The job log is written in English only.

Users can read the job log of jobs that they own, or if they have the system permission List all jobs (9) they can get the job log of any jobs irrespective of their owner.


Job management

Last edited: 10/5/2017 11:51:26 AM

Jobs are mostly managed by the Application Server and rarely need human interference, still there may be cases when you might want to manage jobs (or the job queue) manually. For example in an intense environment where highly prioritized jobs keep coming every second and number of simultaneously allowed jobs is low, a job with a low priority may never be executed. This means administrator should tune system performance or raise a job's priority.

Cancel jobs

All jobs in an active state can be canceled. Depending on the status the job was in when it was canceled the job will be put into another status. See table 1 for details. Jobs that are running, being paused, or paused will be aborted abruptly i.e. they do not get a chance to finish. A user can only cancel jobs he owns. If the user has Jobs: Manage jobs permission he can cancel jobs owned by any users. Jobs with a priority of 1 cannot be canceled by any user.

Status before canceling | Status after canceling
Pending | Closed without execution
Running | Aborted
Being paused | Aborted
Paused | Aborted

Table 1: Status of jobs after cancelling

Suspending execution of new jobs

When the execution of new jobs is suspended, no jobs on the job queue (in pending state) will be executed. Jobs can still be triggered but will not be executed as long as the execution is suspended. Only users with the system permission Jobs: Manage jobs can suspend the execution of new jobs. Jobs with a priority of 1 will still be executed even if the the execution of new jobs is suspended.

Pausing and resuming of jobs

Jobs that are in running state can be paused. When a job is paused, the system will signal job's thread to pause execution. The thread will not be paused immediately but at a point in time when the thread is in some state that allows a clean interruption (which is depending on the job type).

Therefore whenever you pause a job it is put into being paused/paused state. If the job is then actually paused, i.e. the job's thread is not working any more the job is in paused state. The job is not put into paused state automatically but only if the user lists active jobs. Please also note the load balancing logic that applies for paused jobs.

A job in being paused/paused state can be resumed. The job will then immediately resume execution where he left of.

Users can only pause jobs that they own, or if they have the system permission Jobs: Manage jobs also pause jobs of other users. Jobs with a priority of 1 cannot be paused.

Purging archived jobs

All jobs in an archived state will be kept by the system for traceability reasons. The user however has the possibility to purge jobs in archived state that are older than a specific date. To do so the user has to have the system permission Jobs: purge archived jobs.


Jobs on system shutdown

Last edited: 10/5/2017 11:51:26 AM

When application server is shut down it automatically suspends the execution of new jobs All jobs still in an active state will be canceled and put into a specific state listed in table 1. Therefore it is recommended that prior to a planned system shutdown you should suspend the execution of new jobs manually and wait till running jobs are finished.

When application server shut downs unexpectedly (e.g. because of electricity shortage) all jobs in an active state will be obviously terminated. On restart of the Application Server these ghost jobs will be cleaned up and put into the appropriate state as listed in table 1.

Status before system shutdown | Status after restart of the system
Pending | Closed without execution at system shutdown
Running | Aborted at system shutdown
Being paused | Aborted at system shutdown
Paused | Aborted at system shutdown

Table 1: Job states after a system shutdown


Successor jobs

Last edited: 10/5/2017 11:51:26 AM

A job can have successor jobs. Successor jobs are executed only after the job has finished and if the job triggers successor jobs, i.e. the job decides if successor jobs shall be executed or not.

See the documentation of job types for the conditions each job type checks for executing successor jobs. E.g. if the job is an import job that imports data from some other system the successor job could be a job that prepares some presentation of the newly imported data.


Job types

Last edited: 10/5/2017 11:51:26 AM

The system predefines job types that can be instantiated to form new jobs. The job type is the systems processing guideline that tells the system what to do when a job of this type is run with a job of this type.

A job type defines itself if it can be used in a stored job definition or not. The job type also defines the settings that are available for that job type.


Active Directory Synchronization

Last edited: 11/8/2017 9:24:38 AM

The Active Directory synchronization job type is used to synchronize the Redbex users with the users in a specific Active Directory user group.

Characteristic | Description
Successor job triggering | Jobs of this type will trigger successor jobs without any condition.
Can be used in stored job definitions | Yes

Table 1: Characteristics of this job type


Calculated feature execution

Last edited: 10/5/2017 11:51:26 AM

The Calculated feature execution job type is used to execute calculated features. While the execution of calculated features can always be triggered manually (through the used client), this job type allows to automatically execute either a specific feature.

Characteristic | Description
Successor job triggering | Jobs of this type will trigger successor jobs without any condition.
Can be used in stored job definitions | Yes

Table 1: Characteristics of this job type

Setting | Notes
Calculated feature | A single calculated feature that shall be executed.

Table 2: Settings for this job type


%Text%

Navigation: Application Server > Common services > Jobs > Job types >

Check Observation Plan

Last edited: 10/5/2017 11:51:26 AM

This job can be used to check observation plans.

Characteristic | Description
Feature | The feature on which the Observation Plan to execute is defined.
Observation plan | The Observation Plan to be executed.

Table 1: Characteristics of this job type


%Text%

Navigation: Application Server > Common services > Jobs > Job types >

Clean Import Session Logs

Last edited: 10/5/2017 11:51:26 AM

This job us used to clean up (erase) the Job Logs stored for each Import Session. When repeatedly running imports the number of Import Session Logs can grow huge, and the Job Logs stored with each session might therefor use a serious amount of storage space. While the information recorded with each import session (e.g. the files that were imported) is generally important the job log itself is usually not important after some time. Therefore this job can be used to erase the import job logs for import sessions older than a user definable number of days.

Characteristic | Description
Delete if older than | Job Logs for Import Sessions started earlier than current date minus this time span will be erased. Default: 30 days

Table 1: Characteristics of this job type


Execute import definition

Last edited: 10/5/2017 11:51:22 AM

Executes an import definition and therefore imports feature and observation data from files.

Characteristic | Description
Successor job triggering | Jobs of this type will trigger successor jobs if the import was successful or if the import was not successful but the skip errors setting in the import definition was set.
Can be used in stored job definitions | Yes

Table 1: Characteristics of this job type

Setting | Description
Import definition | This specifies the import definition to be executed.

Table 2: Settings for this job type


File references cleanup

Last edited: 10/5/2017 11:51:18 AM

This job type clans up dangling file references and obsolete binary files that may result from various processes that deal with the storage of binary data. It is recommended to have a stored job definition with this job type and a regular schedule.

Characteristic | Description
Successor job triggering | Jobs of this type will trigger successor jobs without any condition.
Can be used in stored job definitions | Yes

Table 1: Characteristics of this job type


Import On The Fly

Last edited: 10/5/2017 11:51:22 AM

This job type is used to run a import definition on the fly. It can only be triggered manually.

Characteristic | Description
Successor job triggering | Never
Can be used in stored job definitions | No

Table 1: Characteristics of this job type


Modular update

Last edited: 11/8/2017 9:32:08 AM

This job us used to execute a Modular Update.

Jobs of this type can not be used in a stored job definition.

Characteristic | Description
Successor job triggering | Never
Can be used in stored job definitions | YES

Table 1: Characteristics of this job type


Recalculate features in view

Last edited: 10/5/2017 11:51:34 AM

The Recalculate features in view job type is used to execute all calculated features that are member of a given view.

Characteristic | Description
Successor job triggering | Jobs of this type will trigger successor jobs without any condition.
Can be used in stored job definitions | Yes

Table 1: Characteristics of this job type

Setting | Notes
View | A view whose calculated member features shall be executed.

Table 2: Settings for this job type


Test job

Last edited: 10/5/2017 11:51:44 AM

This job type can be used for testing the job engine. It does not change any data.

Jobs of this type can be used in a stored job definition.

Characteristic | Description
Successor job triggering | Jobs of this type will trigger successor jobs based on the setting trigger successors.
Can be used in stored job definitions | Yes

Table 1: Characteristics of this job type

Setting | Description
Run length | Defines how long one run of the job will take.
Outcome | Defines what outcome the job shall mimic
Trigger successors | Defines if the job shall trigger the execution of successor jobs.

Table 2: Settings for this job type


Validation

Last edited: 10/5/2017 11:51:44 AM

This job type is used to run the validation for feature and observation data in the background. The job is triggered manually by a user.

Characteristic | Description
Successor job triggering | Never
Can be used in stored job definitions | No

Table 1: Characteristics of this job type


Stored job definitions

Last edited: 10/5/2017 11:51:42 AM

A stored job definition is a the blueprint for a job that is persisted on the Application Server with the intent to perform a job from this definition (repeatedly) at a specific point in time. Stored job definitions can be executed manually, by the job scheduler or as a successor job of other stored job definitions.

Stored job definitions are always owned by the user who last modified them i.e. jobs created from as stored job definition will always impersonate as that user. No user can create stored job definitions for other users.

A user needs the system permission Manage personal stored job definitions (21) to create stored job definitions or modify stored job definitions that he own. Users with the system permission Manage stored jobs definitions (22) can see and modify stored job definitions of other users. Still if a job definition of another user is modified the ownership changes.

Jobs created from a stored job definition will link to the stored job definition they where created from, the other way round you can list all jobs that were created from a specific stored job definition. The owner of stored job definition can list all the jobs triggered triggered from this definition. Users with the system permission Manage stored jobs definitions (22) can also list jobs triggered from stored job definitions owned by other users.

A stored job definition can specify other stored job definitions as follow-ups. When the stored job definition is executed those follow-up jobs will become successor jobs of this job. Note that a stored job definition that is used as follow-up job can still have its own event schedule.

By defining follow-up job definitions for stored job definitions it is theoretically possible to form loops that would end up in an endless execution of the same series of jobs once one of the jobs in this loop is started. The system does not prevent these kind of loops since (in rare cases however) it might be an intended behaviour.


Immediate execution

Last edited: 10/5/2017 11:51:22 AM

The Application Server allows to trigger the execution of stored job definitions immediately. I.e. a job is triggered based on a stored job definition. Only the owner of the store job definition or users with the system permission Manage stored jobs definitions (22) can execute stored job definitions immediately. The job triggered will impersonate as the owner of the stored job definition.

Note that immediate execution means that the a job based on this stored job definition is immediately put on the job queue, i.e. it is up to the job engine when the job is then really executed.


Stored job definition scheduler

Last edited: 10/5/2017 11:51:26 AM

Each stored job definition can optionally define an event schedule. This schedule will then be used by the job scheduler to trigger the execution jobs at defined points in time. Note that due to the load balancing of jobsthe stored job is not necessarily executed exactly at the scheduled point in time but might be delayed.

Each minute the job scheduler checks the all stored job definitions with an event schedule. If the schedule defines a specific job to be run in this minute the job will be triggered by the job scheduler. From that point in time the execution of the job is managed by the job engine.

The job scheduler is started during the startup of the Application Server. If a stored job's event schedule defines triggering a job from a stored job definition for a point in time when the server was down these jobs will not be triggered, i.e. the server does not catch up with work missed during a downtime. You can however use immediate execution to trigger execution of missed jobs.


Managing stored job definitions

Last edited: 10/5/2017 11:51:28 AM

Listing

Stored job definitions including their event schedule (if any) are readable by every user. Each user can list all stored job definitions owned by a specific user, or all stored job definitions on the Application Server. Additionally stored job definitions can be listed filtered by job type.

Jobs that are affecting a specific object can be listed from that specific object. E.g. from a calculated feature the user can list all jobs that initiate the recalculation (and caching) of this calculated feature.

Creating

Users with the system permission Create and modify jobs can create new stored job definitions and assign an event schedule for this definition.

Modifying

A user can always modify stored job definitions and the associated event schedule he owns. Note that even if a user does not have the permission to create stored job definitions (any more) he can still modify existing stored job definitions he owns. Users with the system permission to manage stored job definitions can modify the event schedule of stored job definitions the do not own but cannot modify the stored job definition itself - since this would provide the possibility to impersonate someone else.

Deleting

A user can delete all stored job definition he owns. Users with the system permission to manage stored job definitions can delete stored job definitions of other users.

Enabling disabling event schedules

The Application Server allows to enable or disable the event schedule of a list of stored job definitions. This functionality is run non transactional, i.e. the system will try to disable the event schedule of all specified stored job definitions - each job definition where the requesting user has modify permission will be edited, all other job definitions will be left untouched.


Messaging

Last edited: 10/5/2017 11:51:28 AM

Redbex implements a messaging system that allows to send messages to users and user groups. The messaging system supports full message traceability and message acknowledgement.

Via forwarding rules the messages delivered internally can be forwarded via other media (like email or SMS), this gives you the opportunity to use the power of Redbex's messaging system while still getting messages delivered via your preferred media.

The messaging implemented in Redbex differs from other messaging system like traditional email in the way that each message is stored only once and not copied for each recipient. Only when messages are forwarded via other media like email a (transformed) copy of the message is generated.

Each message sent is sent by a system user (the sender) and is addressed to other system users, user groups- Additionally a message can have (external) email recipients.

When a shut down of the Application Server is initiated the global setting Miscellaneous: Wait time before shutdown [s] defines a time interval that is used to finish currently running tasks before the server. Messages addressed to external recipients that are currently processed will not be sent to external recipients if the processing is interrupted by a shutdown.


Message

Last edited: 10/5/2017 11:51:28 AM

Table 1 summarizes the data a message consist of.

Datum

Description

Sender

The sender of a message. Each message is linked to the Redbex user who sent that message.

Recipients

A list of system internal recipients. While you can address messages to users and user groups, user groups are expanded automatically when the message is sent.

For each recipient the system also stores a flag that defines if that recipient has to acknowledge the message.

Email recipients

A message can have external email recipients. While Redbex can of course not support acknowledgment and other advanced messaging features for external recipients it might be useful to directly send messages to email

Subject

A text template used for the subject of the message. Unicode text up to 400 characters.

Body

A text template used for the message body. Either plain Unicode text or HTML encoded text. No length limitation.

Source context

Describes the context in which a message was created. The context is automatically set by Redbex and cannot be changed by the user. It is however available as a filter in Message forwarding.

Following contexts are used:

·Undefined

·User to User: Set when a user manually sends a message (via used client Software)

·Observation monitoring: Set when a message is created from a message action in observation monitoring

·Observation Plan: Set when a message is created during the evaluation of observation plans.

·Message Acknowledgment Notification: Set when a message is sent as result of a message acknowledgment.

Severity

Severity of the message defined by the sender.

Attachments

Files that are attached to the message. There is no limit to the number or size of attachments. However delivery of attachments via email is usually limited.

Acknowledgment information

Includes the acknowledgment due date and a setting that defines if the sender gets notified whenever a recipient acknowledges a message.

Read marks

Read marks for each recipient

Table 1: data stored with messages.


Message receipients

Last edited: 11/8/2017 9:24:20 AM

Each message has one or more recipients. Recipients can be Redbex system users and user groups.

If the recipients of a message includes user groups the members of this user group are evaluated to users when the message is sent. The message is then associated with each member of the user group. I.e. if the members of a user group change later on this will not influence the recipients of already sent messages. It is also not possible to reconstruct the recipient groups for delivered messages.

When a message is addressed to a user more than once, either through double user recipients or through evaluation of user group, recipients it will still only be associated (delivered) to this user only once.

Recipients can be acknowledging recipients or non-acknowledging recipients. Acknowledging recipients will be asked to acknowledge the receipt of a message, non acknowledging recipients cannot acknowledge the receipt of a message.


Extenal email recipients

Last edited: 10/5/2017 11:51:16 AM

In addition to (internal) recipients a message might also be addressed to external email recipients. Those external recipients will get a translated copy of the original message delivered via SMTP. Acknowledgment is not possible for external email recipients and of course traceability is also not provided.

You can use external recipients if you want to send messages to people that are not system users. Note that due to message translation not all information present in the original message might be available with in the externally sent message.

Addresses for external email recipients must conform to the regular expression shown in listing 1. For example: firstname.lastname@redbex.net would be a valid address, while "Lastname, firstname" <firstname.lastname@redbex.net> would not be valid.

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

Listing 1: Regular expression used for validating the email addresses of external email recipients


Delivery status

Last edited: 10/5/2017 11:51:12 AM

Message delivery to (internal) recipients is always successful, however if a message is also addressed to external recipients the delivery might fail or might fail for some of the external email recipients.

Therefore each sent message has a delivery status that can be on of the values listed in table 1.

If delivery status is not Successful the Delivery log stored with each message might contain more details on why the delivery failed.

Delivery to external recipients is believed to be successful if the message was sent successfully via the external medium, still delivery of external messages might fail later on. This is not reflected in the delivery status.

Delivery status | Description
Successful | Message was delivered successfully to all recipients
Partly successful | Delivery to at least one recipient failed. Can only happen if message has external recipients.
Failed | Delivery to all recipients failed. Can only happen if message has external recipients.

Table 1: Message delivery status


Message severity

Last edited: 10/5/2017 11:51:28 AM

Each message can have a severity that is set by the sender of the message. The message severity can be used by recipients for message forwarding and filtering. It is up to the users how severities are set, the Application Server does not restrict the usage of severities. Therefore the severity should be used with care.

The Application Server supports three severity levels described in table 1.

Severity | Intended usage
Informal | Message is informal. Usually requires no action by recipients.
Warning | Message is a warning and should be carefully noted by recipients. Usually requires no immediate action by recipients.
Critical | Message is important and usually requires immediate action by the recipients.

Table 1: Message severities supported by the Application Server


Message attachements

Last edited: 10/5/2017 11:51:28 AM

You can store any number of message attachments with a message, message attachments can be files of any type and size. Attachments are handled as every other file stored by the Application Server.

Note that while the Application Server does not restrict the size or number of attachments for a message the are usually restrictions when you send a message to an external email recipient or forward a message (via forwarding rules).


Message read marks

Last edited: 10/5/2017 11:51:28 AM

While each message is stored only once on the Application Sever and just linked to the recipients and to the sender, the Application Server can still store read marks for each recipient (separately).

This information is only visible to the recipient.

Its up to the Client to implement handling of read marks e.g. one client might choose to mark a message as read automatically when it is loaded, another client might force you to manually set the read mark.


Deleting and purging messages

Last edited: 10/5/2017 11:51:32 AM

When the recipient of a message deletes the message the message is not really removed from the system but just marked as deleted for this recipient (please note a message is stored only once in the system). When the sender of a message deletes that sent message it is also not deleted but only marked as deleted for the sender.

Received messages that were deleted by the recipient will automatically be member of the Deleted folder. Sent messages deleted by the sender will remain in the sent folder.

Messages that were deleted by the sender and all recipients are called fully deleted messages.

The Application Server allows to purge fully deleted messages i.e. remove those messages permanently from the system.

The application server provides two possibility to purge messages. Each user can initiate purging of the messages he sent. This will automatically purge all fully deleted messages where the user is sender.

Users with the system permission Purge fully deleted messages (5) can purge all fully deleted messages stored on the Application Server.


Message acknowledgment

Last edited: 10/5/2017 11:51:28 AM

The system supports message acknowledgment. I.e. a defined set of acknowledging recipients actively tell the sender that they acknowledge the receipt of the message. In contrast to the delivery notification you might know from your email system, message acknowledgment is done actively by the user and the acknowledgment is not depending on the client and therefore reliable.

A message acknowledgment cannot be undone.

The sender defines who shall to acknowledge the receipt of the message by defining these recipients as acknowledging recipients. Additionally the user can set a acknowledgment due date. The acknowledging recipient has then the possibility to acknowledge the message within the defined acknowledgment time span.

For the recipient a message has always one of the acknowledgment status listed in table 1. For the sender of a message the message has always one of the acknowledgment status listed in table 2.

Received message acknowledgment status | Description
No acknowledgment needed | The recipient is not an acknowledging recipient.
Unacknowledged | The recipient is asked to acknowledge the message, but has not done so yet
Acknowledged | The recipient is asked to acknowledge the message, and has already acknowledged the message

Table 1: Acknowledgment status for received messages

Sent message acknowledgment status | Description
No acknowledgment requested | The message has no acknowledging recipients
Unacknowledged | The message has acknowledging recipients, but none of the recipients has acknowledged the message
Partly acknowledged | The message has acknowledging recipients, and some of the recipients have acknowledged the message
Acknowledged | The message has acknowledging recipients, and all of the recipients have acknowledged the message

Table 2: Acknowledgment status for sent messages

Sender acknowledgment information

The sender of a message can choose to be informed whenever one of the recipients acknowledges that message. An acknowledgment information is a message automatically sent by the system where the sender is the acknowledging user and the recipient is the person who requested the sending of the message. The subject and body of the message will be an automatically created text.


%Text%

Navigation: Application Server > Common services > Messaging >

Message delivery logging

Last edited: 10/5/2017 11:51:28 AM

For each message that is delivered by the Application Server the Application Server writes a delivery log. This delivery log can be used to identify problems with forwarding messages via e-mail, SMS etc.


Message forwarding

Last edited: 10/5/2017 11:51:28 AM

A message sent is first always delivered internally within Redbex, i.e. the message is associated with each recipient within Redbex.

Since users may not check regularly if they have new messages within Redbex, Redbex supports message forwarding. I.e. after the message has been delivered internally within Redbex messages can be forwarded to the users via other delivery media. Table 1 describes the available delivery media.

Delivery medium | Description
E-mail | Used to forward messages to the e-mail address stored with the user. See E-mail forwarding for more details.
SMS | Used to forward messages to the mobile phone numberstored with the user. See SMS forwarding for more details.

Table 1: Available delivery media for forwarding messages

Message forwarding is configured by the definition of message forwarding rules. A message forwarding rule consists of the specification of a forwarding medium and a filter that defines to which messages the forwarding rule applies. Table 2 shows the filter possibilities of a forwarding rule.

There are global message forwarding rules and personal message forwarding rules. Global message forwarding rules apply when a message is delivered to a user who has not defined any personal message forwarding rules. A user can create or modify global message forwarding rules only if he has the system permission Manage message forwarding rules (28). Personal forwarding rules can be created and modified by the user they belong to or by users with the system permission Manage message forwarding rules (28).

Processing of forwarding rules

After a message is delivered to a Redbex user, Redbex will check the effective forwarding rules that apply to that user. If the user has any personal forwarding rule defined the effective forwarding rules are only his personal forwarding rules. If the user has no personal forwarding rules defined the effective forwarding rules are the global forwarding rules. If neither personal nor global forwarding rules are defined Redbex automatically uses a default forwarding rule that forwards all messages via e-mail.

For each possible delivery medium the system will then check if there is at least one rule for this delivery medium whose filter matches the delivered message. If so the message will be forwarded via that delivery medium.

Forwarding rules filter

A forwarding rule matches to a message if the message passes all the filter conditions defined in that forwarding rule. see table 1 for a description of the filter conditions

Setting

Description

Severity from

Only messages with a severity greater or equal this severity will be forwarded by this rule. If left undefined there is no lower boundary for message severity.

Severity to

Only messages with a severity lower or equal this severity will be forwarded by this rule. If left undefined there is no upper boundary for message severity.

Filter expression type

Defines how the filter expression (see below) will e interpreted by Redbex.

·Contains: the given filter expression must be contained somewhere within the filter expression scope. With this type set the filter expression is case insensitive.

·Simple wildcard: the given filter expression must match the given scope exactly but can include simple wildcards.

·Regular expression: the given filter expression is interpreted as a regular expression and matched against the filter expression scope

Filter expression scope

Defines to which parts of the message the filter expression is matched. Possible options are:

·Subject

·Body

·Subject or Body

Filter expression

The applied filter expression. If empty this filter will be skipped. The case sensitivity of this filter expression is defined by the filter expression type (see above).

Source context

If given only messages with that source context will be forwarded by the rule.

Table 2: Filtering possibilities provided in a message forwarding rule

Logging

For traceability reasons the system logs for each message delivered to a system user via which delivery medium and to which address it was forwarded. I.e. even if a user changes his forwarding rules later on it can still be seen to which addresses the message was forwarded.

Message Transformation

When messages are forwarded via other delivery media or when messages are sent to external recipients the message has to be transformed to fit this transport media, e.g. SMS messages have limited character count and therefore the original message has to be shortened before sending.

Note: Due to technical restrictions of the target delivery medium there might be an information loss during message transformation.


SMS forwarding

Last edited: 10/5/2017 11:51:28 AM

The actual service used to send SMS (Short Message Service) depends on your Global settings. If SMPP is configured in global settings the Message will be forwarded via this service, if not it will be forwarded via Twilio. If no SMS service is configured the forwarding will fail.

Twilio SMS

Messages will be sent via the Twilio SMS Service. (http://www.twilio.com).

You need to purchase a Twilio Account to use Twilio SMS. This medium uses Twilio's Web Service API to send SMS. You may need to adapt the firewall settings in the Application Server's environment for this forwarding medium to work.

SMPP forwarding

SMPP (Short Message peer-to-peer protocol) is a telecommunications industry protocol for exchanging SMS messages between SMS peer entities such as short message service centers. Redbex supports forwarding of messages via SMPP version 3.4

You may need to adapt the firewall settings in the Application Server's environment for this forwarding medium to work.

The configuration for SMPP is done in the global settings.

Message transformation

Messages forwarded via SMS will be sent to recipients as SMS (Short Message Service). SMS is a medium that limits the size of the sent messages.

When forwarding a message via SMS the Application Server will transform the original message in following way:

RB:<sender's username>

S:<subject of original message>

B:<Message body>

HTML formatting of the message body will be automatically removed.

If the constructed SMS exceeds the maximum number of characters allowed for a single SMS (defined in the Global Settings) the message will be truncated and the an ellipsis will be added at the end of the message.

If the maximum size of SMS messages specified in the Global settings exceeds the size allowed by the carrier, the carrier will either split the SMS into several SMS or will truncate the SMS himself.


E-mail forwarding

Last edited: 10/5/2017 11:51:28 AM

Messages will be sent via the configured SMTP.

E-mail transformation

Table 1 describes how a message is transformed in to an e-mail message. See also chapter Email format for more details on e-mails sent by the Application Server.

Email part

Content

Content type: header field

Will be text

Priority header field

The message severity is translated to email priority as indicated by Table 2

Subject header field

Contains the subject of the message

Email body

Contains the body of the message.

For the information of the recipient of the email the Application Server will additionally add following information to the email body:

·Recipient list: system users (username and real name, acknowledgment required), external users (transport media, address)

·Message severity

·Need to acknowledge: Information if the recipient is an acknowledging recipient (only works for forwarded messages not for external recipients)

Attachments

Attachments to messages will be added to emails as attachments if the global setting SMTP: Allow attachments is set.

Table 1: Translation of a message to an email

Message severity | Translated email priority
Informal | Low
Warning | Medium
Critical | High

Table 2: Translation of message severity to email priority


Message folders

Last edited: 10/5/2017 11:51:28 AM

Sent and received messages can be organized in message folders. There are predefined system folders (Inbox, Outbox and Wastebasket) and additionally each user can create his own user folders for better organization of his messages.


System folders

Last edited: 10/5/2017 11:51:42 AM

Inbox, Outbox and Wastebasket are three predefined message folders that behave similarly to the folders you might know from your email clients. These three folders always available and cannot be modified.

Table 1 explains which messages are shown in what folder.

Folder | Description and content
Inbox | All messages received by a user that were not moved to a user defined folder and were not marked as deleted
Outbox | All messages sent by a user and not deleted
Deleted | All sent and received messages marked as deleted for the current user

Table 1: Options for the folder setting of the Inbox, Outbox, Wastebasket message filter term type


User folder

Last edited: 10/5/2017 11:51:44 AM

User folders can be used to structure sent and received messages. Each user can create his own hierarchically structured user folder structure and assign messages (both sent and retrieved) to a folder. One message can be assigned to one message folder only.


%Text%

Navigation: Application Server > Common services >

Data Change Logging

Last edited: 10/5/2017 11:51:12 AM

The Application Server provides the possibility to write a log of changes to data, including creation modification and deletion of data. This possibility can be used to create continuous change logs that allow to trace back who changed data at what point in time and also how data was changed. The Data Change Log functionality is meant to be used if you are working in an environment where you are forced by legislation to record changes made to data.

Tracking data changes configured with Global Settings.

The data changes are logged in SQLite databases that are stored in the Optional Logs directory specified in the Instance Configuration of your Application Server instance. The database files are named in the format DataChangeLog_<DATETIME>.sqlite3 where <DATETIME> is time of file creation in the format yyyy-MM-ddTHHmmss. For best performance we recommend to store the log files on a separate physical disc attached to the Application Server.

Note: The databases created for data change logging should also be included in your backup plan. Note that simply copying SQLite database files is not necessarily a valid backup for SQLite databases, please consult the SQLite documentation for more details.

Limiting size of database files

The change logging functionality might record a huge amount of data and therefore the databases might grow quickly. SQLite databases are able to hold an enormous amount of data - Depending on your operating system, the file system the database is stored in, your backup strategy etc. it is however advisable to limit the maximum size of SQLite database files. Using the Global Setting Changes per transaction you can therefore define a maximum size for the SQLite database files. When the maximum size is exceeded the Application Server will change to a new database file.

Performance and data safety considerations

For performance reasons each change that shall be recorded in the data change log is first only written to a queue in memory. A separate thread monitors this queue and and persists the changes to the SQLite database. This way the impact of writing change logs on the performance of the overall system is kept minimal.

Usually writing to the change log database is much faster than persisting of the actual change to the Application Server Database. Still under some circumstances the in-memory queue might grow because persisting of the change log is not fast enough, the in memory queue therefore acts as a buffer. The in memory queue has a maximum size that is defined by the global setting Max cache size. If that maximum size is reached the actual data change (e.g. the modification of an observation) will be delayed until the task writing the change logs free the size of the queue again.

Note that all change log entries that are not yet persisted will be lost in case of a sudden server failure (e.g. fatal software defect, power outage etc). You may adjust this setting to balance memory usage of the Application Server, write performance and data safety according to your needs.

The thread that persists the entries of the in-memory queue works with transactions. I.e. a set of change log entries are persisted together. This improves the write performance to the change log database drastically. However this also means that change log entries are not necessarily persisted immediately after they have been added to the queue, but the Application Server might wait till there are enough change log entries to be persisted and will the persist them in one set. How many change log entries are added to a single transaction can be defined using the global setting Changes per transaction.

To prevent the situation that a few changes are kept on the queue for a long time because no new changes are added to the queue and the Changes per transaction threshold is not reached, there is an additional timer that will persist those changes after the number of seconds set with the global setting Maximum transaction wait time.

Again in case of a sudden server failure all change log entries on the in-memory queue that were not persisted will be lost. You may adjust these settings to balance write performance to the change logging database and data safety.

Log database Schema

Each log database includes a table called DbMetaInformation that specifies the schema version of the database as well as the creation date of the database. All other tables in the database schema are used to record the changes of different types e.g. changes to observations, changes to features etc. Following chapters describe each of these tables in detail.

Evaluating the change log data

Redbex does not provide any evaluation functionality for the change log database. It is up to the user to use standard SQL commands to evaluate the change log according to his needs.

Figure 1: Schematic overview of data change logging


FeatureChanges

Last edited: 10/5/2017 11:51:12 AM

Changes to observations are logged in the FeatureChanges table.

Colum | SQLite DataType | Description
Id | INTEGER | Id of the record
Timestamp | TEXT | Timestamp of the change
UserId | INTEGER | Id of the user who initiated the change
FeatureId | INTEGER | Id of the feature that was changed
ChangeType | TEXT | Type of change performed (see table 2 for a description of change types)
FeatureName | TEXT | Name of the feature that was changed
ChangeDetails | TEXT | Details about the change as JSON formatted string (content depends on type of change)

Table 1: Description of the FeatureChanges table.

Change type | Description
C | Creation of a feature
D | Deletion of a feature
M | Modification of a feature
MG | Modification of a feature's geometry
MR | Modification of a feature's spatial reference system link. I.e. if a feature uses another spatial reference system.

Table 2: Change types for features


ObservationChanges

Last edited: 10/5/2017 11:51:12 AM

Changes to observations are logged in the ObservationChanges table.

Colum | SQLite DataType | Description
Id | INTEGER | Id of the record
Timestamp | TEXT | Timestamp of the change
UserId | INTEGER | Id of the user who initiated the change
FeatureId | INTEGER | Id of the feature to which the changed observation belongs
ObservationId | INTEGER | Id of the observation
ChangeType | TEXT | Type of change performed (see table 2 for a description of change types)
SamplingTimestamp | TEXT | Sampling timestamp of the observation (not written for all change types)
ChangeDetails | TEXT | Details about the change as JSON formatted string (content depends on type of change)

Table 1: Description of the ObservationChanges table.

Change type | Description
C | Creation of an observation
D | Deletion of an observation
M | Modification of observation
ME | Modification of observation's erroneous flag
MG | Modification of observation's geometry

Table 2: Change types for observations

Notes

·Changes performed by in-feature calculations are not logged

·Deletion of observations as part of the execution of a calculated algorithm are not logged.


General information

Last edited: 10/5/2017 11:51:20 AM

This chapter is a collection of topics that describe basic concepts and fundamental services of the Application Server.


Globalization, Localization

Last edited: 10/5/2017 11:51:04 AM

Redbex is a globalized application, i.e. it considers numerous factors, such as languages issues, date format issues and other string-related issues. For a single user or a single installation it is however possible to localize Redbex, i.e. it is possible to configure Redbex in to meet the requirements for a given culture and locale.

The following chapters explain the globalized and localizable functionalities of the Redbex Application Server. Note that in some cases the localization has to be done by the used client (for Smart Client localization see chapter Globalization, Localization).


Multi-language support

Navigation: Application Server > General information > Globalization, Localization >

Multi language support

Last edited: 11/8/2017 9:31:50 AM

When you think of software that is available in multiple languages you usually think of the user interface, where all the labels are displayed in the language you choose. The Application Server itself has no user interface, still there is textual information that is generated by the Application Server and sent to clients for display. E.g. names of properties in property structures, error messages, server feedback messages and others more. For this kind of data the application server supports multiple languages.

The language used by the Application Server uses when responding to requests of a user is defined in the user account of the currently accessing user; i.e. the responses of the Application Server can be in different languages for different users.

Note that the Application Server might not support all languages the used client supports, i.e. it can be that the client's user interface (e.g. the Smart Client) is shown in a specific language, but the data sent from the Application Server is in the default language English.


%Text%

Navigation: Application Server > General information > Globalization, Localization >

Multilingual data

Last edited: 10/5/2017 11:51:28 AM

To support multilingual teams and projects, some textual data the user enters and stores on he application server can be entered in multiple languages. This concept is called multilingual data.

Wherever the application server supports multilingual data the client will present data entry controls where the user can switch between languages for entering and displaying data.

Multilingual data can be defined in any of the languages supported by the Application Server. An additional Invariant language can be used to define language independent texts.


Unicode support

Last edited: 10/5/2017 11:51:44 AM

Unicode is a standard for the consistent encoding, representation and handling of text expressed in most of the world's writing systems. If not explicitly stated otherwise in this Reference Manual the Application Server stores all textual information encoded in UTF-8.


Cultures

Last edited: 11/8/2017 9:24:06 AM

When displaying date and time values or numeric values different cultures use different formatting. In the usual interaction between client and Application Server the Application Server will format data according to the Culture set for the user (see chapter User for more details). Table 1 shows the characteristics for number and date time formatting defined by the used culture.

There are some places (like importing data from files) where the Application Server allows or requires the declaration of a culture (and does not implicitly assume the user's or client's culture).

The Application Server supports a wide variety of cultures. The actual cultures supported depend on the Operating System on which the Application Server is run. A listing of Cultures and their characteristics that are usually available with all operating systems can be found on the Redbex web site.

Characteristic | Description
Decimal separator | The decimal separator used when displaying numbers or when parsing strings to numbers.
Grouping separator | The grouping separator used when displaying numbers or when parsing strings to numbers.
Date separator | The character used for separating the parts of a date value.
Time separator | The character used for separating the parts of a time value. (hours, minutes, seconds). The separator for partial seconds is again the decimal separator.
AM/PM designator | The designator used for time values when a 12 hour clock is used
Short date pattern | Defines how date or date time or date time offset values are shown if the short date pattern (d) is used. See Date & time formatting for more information on date formatting patterns,
Long date pattern | Defines how date or date time or date time offset values are shown if the long date pattern (D) is used. See Date & time formatting for more information on date formatting patterns,
Day names | Defines the day names used in this culture.
Month names | Defines the Month names used in this culture.

Table 1: Characteristics for date and number formatting defined by the Culture


Date-Time-Offset

Last edited: 10/23/2017 8:11:48 AM

A Date & Time value like 2010-02-05 18:12:24 is ambiguous, depending on the Time Zone in which that value is interpreted it would express different points in time. While we are usually interpreting Date & Time values in the Time zone we live in and we therefore usually do not have to deal with the ambiguous character of those Date & Time values. But as soon as we have to deal with date & time values originating from different time zones things get more difficult.

To be able to handle date originating from different time zones Redbex uses Date-Time-Offset values. Date-Time-Offset values like 2010-02-05 18:12:24 +01:00 represent instantaneous time (or absolute time) relative to Coordinated Universal Time, they are universal and unambiguous for everyone (not accounting for leap seconds, or the relativistic effects of time dilation).

Note that even if you are usually working in only one time zone you might be confronted with data coming from different time zones. Some sensors for example do not switch between summer time and winter time and therefore define their own 'artificial' time zone.

The offset part of the value (+01:00) can take values from -14:00 to +14:00 and expresses the offset that has to be subtracted from the date part in order to get UTC.

Example: Using Date-Time-Offset The date time value of 2010-02-05 18:12:24.198 expressed in MST (Mountain standard time) would be stored by the Application Server as 2010-02-05 18:12:24.198 -06:00.

Using Date-Time-Offset makes data originating from different Time zones comparable:

·2010-02-05 18:12:24 +01:00 = 2010-02-05 19:12:24 +02:00 = 2010-02-05 17:12:24 +00:00

·2010-02-05 18:12:24 +01:30 > 2010-02-05 18:12:24 +02:00

·2010-02-05 18:12:24.198 -06:00 = 2010-02-06 00:12:24.198 00:00

·2010-02-05 18:12:24.198 +04:00 = 2010-02-06 14:12:24.198 00:00

·2010-02-05 18:12:24.198 -04:00 = 2010-02-05 23:12:24.198 01:00

Date-Time-Offset values are always expressed in the Gregorian calendar. The system supports date values ranging from 0001-01-01 and 9999-12-31, however values might be restricted in the context where you are using them. Time values can range from 00:00:00 through 23:59:59.9999999 therefore giving you a theoretical maximum precision of 100 nanoseconds, again the maximum precision can be restricted in the context where you use the Date-Time-Offset value.


Date-time formatting

Last edited: 11/14/2017 8:52:30 AM

Formatting date-time values for display or defining the pattern how strings shall be parsed by Redbex into date-time values (e.g. during import of data) is tricky, since the number of different date and time formats is nearly endless. E.g. February, 11th 2016 could be written as 11/2/2016 (USA) or as 2.11.2016 (German) or as 2016-02-11 (Sweden).

To give you maximum flexibility for formatting and parsing date-time values Redbex uses date-time formatting strings. In many places where a date and time value is presented (e.g. in a chart, on a report or in an export file) you can define how that date-time value will be formatted by defining a formatting string. In many places where Redbex reads date-time strings (e.g in import definitions) you have the possibility to define how the software shall parse that string to produce a valid date-time value by defining a formatting string.

Date-time format strings are blue prints that define how a date-time (or date-time-offset) value shall be formatted for display or how a string shall be parsed to get a date-time value from it.

When applying date time format strings for displaying or reading date time the currently set Culture plays an important role, it defines the used date separator, time separator, AM/PM designators, day names and month names etc. Therefore in most places where you can define date-time format strings you can also define a culture.

There are two types of format strings standard format strings and custom format strings. Standard format strings are single letter stings that are shortcuts for specific standardized date-time representations according to the current culture. See table 2 for a listing of all available standard format strings.

Custom format strings are all format strings longer than one character that allow the free definition of nearly any date time format. See table 3 for a listing of format specifiers that can be used in custom format strings.

Note that standard format strings are only single letter strings and cannot be combined with other format strings. Any formatting string longer than one character will always be interpreted as custom format string.

Table 1 shows examples how a given date time value is presented with different format strings in the EN-US culture.

Date time value | Format string | Result when displaying with format string (using EN-US culture)
2014-02-11 08:34:12.1234567 | d (standard format string) | 2/11/2014
 | D (standard format string) | February 02, 2014
 | MMMM dd, yyyy (custom format string) | February 02, 2014
 | ddd d MMM (custom format string) | Tue 11 Feb
 | dddd dd MMMM (custom format string) | Tuesday 11 February
 | hh:mm:ss.f (custom format string) | 08:34:12.1

Table 1: Examples of date & time format strings

Standard Format string | Description | Examples
d | Short date pattern. The d standard format specifier represents a custom date and time format string that is defined by the currently set culture. | 6/15/2009 1:45:30 PM -> 6/15/2009 (en-US) 6/15/2009 1:45:30 PM -> 15/06/2009 (fr-FR) 6/15/2009 1:45:30 PM -> 2009/06/15 (ja-JP)
D | Long date pattern. The D standard format specifier represents a custom date and time format string that is defined by the currently set culture. | 6/15/2009 1:45:30 PM -> Monday, June 15, 2009 (en-US) 6/15/2009 1:45:30 PM -> 15 июня 2009 г. (ru-RU) 6/15/2009 1:45:30 PM -> Montag, 15. Juni 2009 (de-DE)
f | Full date/time pattern (short time). | 6/15/2009 1:45:30 PM -> Monday, June 15, 2009 1:45 PM (en-US) 6/15/2009 1:45:30 PM -> den 15 juni 2009 13:45 (sv-SE) 6/15/2009 1:45:30 PM -> Δευτέρα, 15 Ιουνίου 2009 1:45 μμ (el-GR)
F | Full date/time pattern (long time). | 6/15/2009 1:45:30 PM -> Monday, June 15, 2009 1:45:30 PM (en-US) 6/15/2009 1:45:30 PM -> den 15 juni 2009 13:45:30 (sv-SE) 6/15/2009 1:45:30 PM -> Δευτέρα, 15 Ιουνίου 2009 1:45:30 μμ (el-GR)
g | General date/time pattern (short time). | 6/15/2009 1:45:30 PM -> 6/15/2009 1:45 PM (en-US) 6/15/2009 1:45:30 PM -> 15/06/2009 13:45 (es-ES) 6/15/2009 1:45:30 PM -> 2009/6/15 13:45 (zh-CN)
G | General date/time pattern (long time). | 6/15/2009 1:45:30 PM -> 6/15/2009 1:45:30 PM (en-US) 6/15/2009 1:45:30 PM -> 15/06/2009 13:45:30 (es-ES) 6/15/2009 1:45:30 PM -> 2009/6/15 13:45:30 (zh-CN)
M, m | Month/day pattern. | 6/15/2009 1:45:30 PM -> June 15 (en-US) 6/15/2009 1:45:30 PM -> 15. juni (da-DK) 6/15/2009 1:45:30 PM -> 15 Juni (id-ID)
O, o | Round-trip date/time pattern. | 6/15/2009 1:45:30 PM -> 2009-06-15T13:45:30.0900000
R, r | RFC1123 pattern. | 6/15/2009 1:45:30 PM -> Mon, 15 Jun 2009 20:45:30 GMT
s | Sortable date/time pattern. | 6/15/2009 1:45:30 PM -> 2009-06-15T13:45:30
t | Short time pattern. | 6/15/2009 1:45:30 PM -> 1:45 PM (en-US) 6/15/2009 1:45:30 PM -> 13:45 (hr-HR) 6/15/2009 1:45:30 PM -> 01:45 م (ar-EG)
T | Long time pattern. | 6/15/2009 1:45:30 PM -> 1:45:30 PM (en-US) 6/15/2009 1:45:30 PM -> 13:45:30 (hr-HR) 6/15/2009 1:45:30 PM -> 01:45:30 م (ar-EG)
u | Universal sortable date/time pattern. | 6/15/2009 1:45:30 PM -> 2009-06-15 20:45:30Z
U | Universal full date/time pattern. | 6/15/2009 1:45:30 PM -> Monday, June 15, 2009 8:45:30 PM (en-US) 6/15/2009 1:45:30 PM -> den 15 juni 2009 20:45:30 (sv-SE) 6/15/2009 1:45:30 PM -> Δευτέρα, 15 Ιουνίου 2009 8:45:30 μμ (el-GR)
Y, y | Year month pattern. | 6/15/2009 1:45:30 PM -> June, 2009 (en-US) 6/15/2009 1:45:30 PM -> juni 2009 (da-DK) 6/15/2009 1:45:30 PM -> Juni 2009 (id-ID)
Any other single character | Interpreted as custom format string. |

Table 2: Standard date time formatting strings

Format specifier | Description | Examples
d | The day of the month, from 1 through 31. The d custom format specifier represents the day of the month as a number from 1 through 31. A single-digit day is formatted without a leading zero. | 6/1/2009 1:45:30 PM -> 1 6/15/2009 1:45:30 PM -> 15
dd | The day of the month, from 01 through 31. The dd custom format string represents the day of the month as a number from 01 through 31. A single-digit day is formatted with a leading zero. | 6/1/2009 1:45:30 PM -> 01 6/15/2009 1:45:30 PM -> 15
ddd | The abbreviated name of the day of the week. The ddd custom format specifier represents the abbreviated name of the day of the week. The abbreviation will reflect the culture setting of the Application Server. | 6/15/2009 1:45:30 PM -> Mon (en-US) 6/15/2009 1:45:30 PM -> Пн (ru-RU) 6/15/2009 1:45:30 PM -> lun. (fr-FR)
dddd | The full name of the day of the week. The dddd custom format specifier (plus any number of additional d specifiers) represents the full name of the day of the week. The abbreviation will reflect the culture setting of the Application Server. | 6/15/2009 1:45:30 PM -> Monday (en-US) 6/15/2009 1:45:30 PM -> понедельник (ru-RU) 6/15/2009 1:45:30 PM -> lundi (fr-FR)
f | The tenths of a second in a date and time value. The f custom format specifier represents the most significant digit of the seconds fraction; that is, it represents the tenths of a second in a date and time value. | 6/15/2009 13:45:30.617 -> 6 6/15/2009 13:45:30.050 -> 0
ff | The hundredths of a second in a date and time value. | 6/15/2009 13:45:30.617 -> 61 6/15/2009 13:45:30.005 -> 00
fff | The milliseconds in a date and time value. | 6/15/2009 13:45:30.617 -> 617 6/15/2009 13:45:30.0005 -> 000
ffff | The ten thousandths of a second in a date and time value. | 6/15/2009 13:45:30.6175 -> 6175 6/15/2009 13:45:30.00005 -> 0000
fffff | The hundred thousandths of a second in a date and time value. | 6/15/2009 13:45:30.61754 -> 61754 6/15/2009 13:45:30.000005 -> 00000
ffffff | The millionths of a second in a date and time value. | 6/15/2009 13:45:30.617542 -> 617542 6/15/2009 13:45:30.0000005 -> 000000
fffffff | The ten millionths of a second in a date and time value. | 6/15/2009 13:45:30.6175425 -> 6175425 6/15/2009 13:45:30.0001150 -> 0001150
F | If non-zero, the tenths of a second in a date and time value. | 6/15/2009 13:45:30.617 -> 6 6/15/2009 13:45:30.050 -> (no output)
FF | If non-zero, the hundredths of a second in a date and time value. | 6/15/2009 13:45:30.617 -> 61 6/15/2009 13:45:30.005 -> (no output)
FFF | If non-zero, the milliseconds in a date and time value. | 6/15/2009 13:45:30.617 -> 617 6/15/2009 13:45:30.0005 -> (no output)
FFFF | If non-zero, the ten thousandths of a second in a date and time value. | 6/1/2009 13:45:30.5275 -> 5275 6/15/2009 13:45:30.00005 -> (no output)
FFFFF | If non-zero, the hundred thousandths of a second in a date and time value. | 6/15/2009 13:45:30.61754 -> 61754 6/15/2009 13:45:30.000005 -> (no output)
FFFFFF | If non-zero, the millionths of a second in a date and time value. | 6/15/2009 13:45:30.617542 -> 617542 6/15/2009 13:45:30.0000005 -> (no output)
FFFFFFF | If non-zero, the ten millionths of a second in a date and time value. | 6/15/2009 13:45:30.6175425 -> 6175425 6/15/2009 13:45:30.0001150 -> 000115
g, gg | The period or era. | 6/15/2009 1:45:30 PM -> A.D.
h | The hour, using a 12-hour clock from 1 to 12. | 6/15/2009 1:45:30 AM -> 1 6/15/2009 1:45:30 PM -> 1
hh | The hour, using a 12-hour clock from 01 to 12. More information: The hh Custom Format Specifier. | 6/15/2009 1:45:30 AM -> 01 6/15/2009 1:45:30 PM -> 01
H | The hour, using a 24-hour clock from 0 to 23. | 6/15/2009 1:45:30 AM -> 1 6/15/2009 1:45:30 PM -> 13
HH | The hour, using a 24-hour clock from 00 to 23. | 6/15/2009 1:45:30 AM -> 01 6/15/2009 1:45:30 PM -> 13
K | Time zone information. | With DateTime values: 6/15/2009 1:45:30 PM, Kind Unspecified -> 6/15/2009 1:45:30 PM, Kind Utc -> Z 6/15/2009 1:45:30 PM, Kind Local -> -07:00 (depends on local computer settings) With DateTimeOffset values: 6/15/2009 1:45:30 AM -07:00 --> -07:00 6/15/2009 8:45:30 AM +00:00 --> +00:00
m | The minute, from 0 through 59. | 6/15/2009 1:09:30 AM -> 9 6/15/2009 1:09:30 PM -> 9
mm | The minute, from 00 through 59. | 6/15/2009 1:09:30 AM -> 09 6/15/2009 1:09:30 PM -> 09
M | The month, from 1 through 12.. | 6/15/2009 1:45:30 PM -> 6
MM | The month, from 01 through 12. | 6/15/2009 1:45:30 PM -> 06
MMM | The abbreviated name of the month. | 6/15/2009 1:45:30 PM -> Jun (en-US) 6/15/2009 1:45:30 PM -> juin (fr-FR) 6/15/2009 1:45:30 PM -> Jun (zu-ZA)
MMMM | The full name of the month. | 6/15/2009 1:45:30 PM -> June (en-US) 6/15/2009 1:45:30 PM -> juni (da-DK) 6/15/2009 1:45:30 PM -> uJuni (zu-ZA)
s | The second, from 0 through 59. More information: The s Custom Format Specifier. | 6/15/2009 1:45:09 PM -> 9
ss | The second, from 00 through 59. | 6/15/2009 1:45:09 PM -> 09
t | The first character of the AM/PM designator. | 6/15/2009 1:45:30 PM -> P (en-US) 6/15/2009 1:45:30 PM -> 午 (ja-JP) 6/15/2009 1:45:30 PM -> (fr-FR)
tt | The AM/PM designator. | 6/15/2009 1:45:30 PM -> PM (en-US) 6/15/2009 1:45:30 PM -> 午後 (ja-JP) 6/15/2009 1:45:30 PM -> (fr-FR)
y | The year, from 0 to 99. More information: The y Custom Format Specifier. | 1/1/0001 12:00:00 AM -> 1 1/1/0900 12:00:00 AM -> 0 1/1/1900 12:00:00 AM -> 0 6/15/2009 1:45:30 PM -> 9
yy | The year, from 00 to 99. | 1/1/0001 12:00:00 AM -> 01 1/1/0900 12:00:00 AM -> 00 1/1/1900 12:00:00 AM -> 00 6/15/2009 1:45:30 PM -> 09
yyy | The year, with a minimum of three digits. | 1/1/0001 12:00:00 AM -> 001 1/1/0900 12:00:00 AM -> 900 1/1/1900 12:00:00 AM -> 1900 6/15/2009 1:45:30 PM -> 2009
yyyy | The year as a four-digit number. | 1/1/0001 12:00:00 AM -> 0001 1/1/0900 12:00:00 AM -> 0900 1/1/1900 12:00:00 AM -> 1900 6/15/2009 1:45:30 PM -> 2009
yyyyy | The year as a five-digit number. | 1/1/0001 12:00:00 AM -> 00001 6/15/2009 1:45:30 PM -> 02009
z | Hours offset from UTC, with no leading zeros.. | 6/15/2009 1:45:30 PM -07:00 -> -7
zz | Hours offset from UTC, with a leading zero for a single-digit value. | 6/15/2009 1:45:30 PM -07:00 -> -07
zzz | Hours and minutes offset from UTC. | 6/15/2009 1:45:30 PM -07:00 -> -07:00
: | The time separator. (according to the set Culture) | 6/15/2009 1:45:30 PM -> : (en-US) 6/15/2009 1:45:30 PM -> . (it-IT) 6/15/2009 1:45:30 PM -> : (ja-JP)
/ | The date separator. (according to the set Culture) | 6/15/2009 1:45:30 PM -> / (en-US) 6/15/2009 1:45:30 PM -> - (ar-DZ) 6/15/2009 1:45:30 PM -> . (tr-TR)
string 'string' | Literal string delimiter. | 6/15/2009 1:45:30 PM (arr: h:m t) -> arr: 1:45 P 6/15/2009 1:45:30 PM ('arr:' h:m t) -> arr: 1:45 P
% | Defines the following character as a custom format specifier. (especially useful if the format string consists of only one letter but you want that letter to be interpreted as custom format string). | 6/15/2009 1:45:30 PM (%h) -> 1
\ | The escape character. | 6/15/2009 1:45:30 PM (h \h) -> 1 h
Any other character | The character is copied to the result string unchanged. | 6/15/2009 1:45:30 AM (arr hh:mm t) -> arr 01:45 A

Table 3: Format specifiers that can be used in custom date & time format strings


Number formatting

Last edited: 10/5/2017 11:51:30 AM

In several places the Application Server allows to specify the format in which numeric values shall be displayed or parsed (e.g. in text templates) by providing a numeric format string and a culture. You can use standard numeric format strings or custom numeric format strings to specify the formatting of the numeric value.

Standard numeric format strings are used to format common numeric types. A standard numeric format string takes the form Axx, where:

·A is a single alphabetic character called the format specifier. Any numeric format string that contains more than one alphabetic character, including white space, is interpreted as a custom numeric format string. For more information, see Custom Numeric Format Strings.

·xx is an optional integer called the precision specifier. The precision specifier ranges from 0 to 99 and affects the number of digits in the result. Note that the precision specifier controls the number of digits in the string representation of a number. It does not round the number itself.

Table 1 lists the available standard format strings.

You can create a custom numeric format string, which consists of one or more custom numeric specifiers, to define how to format numeric data. A custom numeric format string is any format string that is not a standard numeric format string.

Table 2 gives an overview on custom numeric format strings.

Format specifier | Name | Description | Examples
"C" or "c" | Currency | Result: A currency value. Supported by: All numeric types. Precision specifier: Number of decimal digits. Default precision specifier: Defined byNumberFormatInfo.CurrencyDecimalDigits. | 123.456 ("C", en-US) -> $123.46 123.456 ("C", fr-FR) -> 123,46 € 123.456 ("C", ja-JP) -> ¥123 -123.456 ("C3", en-US) -> ($123.456) -123.456 ("C3", fr-FR) -> -123,456 € -123.456 ("C3", ja-JP) -> -¥123.456
"D" or "d" | Decimal | Result: Integer digits with optional negative sign. Supported by: Integral types only. Precision specifier: Minimum number of digits. Default precision specifier: Minimum number of digits required. | 1234 ("D") -> 1234 -1234 ("D6") -> -001234
"E" or "e" | Exponential (scientific) | Result: Exponential notation. Supported by: All numeric types. Precision specifier: Number of decimal digits. Default precision specifier: 6. | 1052.0329112756 ("E", en-US) -> 1.052033E+003 1052.0329112756 ("e", fr-FR) -> 1,052033e+003 -1052.0329112756 ("e2", en-US) -> -1.05e+003 -1052.0329112756 ("E2", fr_FR) -> -1,05E+003
"F" or "f" | Fixed-point | Result: Integral and decimal digits with optional negative sign. Supported by: All numeric types. Precision specifier: Number of decimal digits. Default precision specifier: Defined byNumberFormatInfo.NumberDecimalDigits. | 1234.567 ("F", en-US) -> 1234.57 1234.567 ("F", de-DE) -> 1234,57 1234 ("F1", en-US) -> 1234.0 1234 ("F1", de-DE) -> 1234,0 -1234.56 ("F4", en-US) -> -1234.5600 -1234.56 ("F4", de-DE) -> -1234,5600
"G" or "g" | General | Result: The most compact of either fixed-point or scientific notation. Supported by: All numeric types. Precision specifier: Number of significant digits. Default precision specifier: Depends on numeric type. | -123.456 ("G", en-US) -> -123.456 123.456 ("G", sv-SE) -> -123,456 123.4546 ("G4", en-US) -> 123.5 123.4546 ("G4", sv-SE) -> 123,5 -1.234567890e-25 ("G", en-US) -> -1.23456789E-25 -1.234567890e-25 ("G", sv-SE) -> -1,23456789E-25
"N" or "n" | Number | Result: Integral and decimal digits, group separators, and a decimal separator with optional negative sign. Supported by: All numeric types. Precision specifier: Desired number of decimal places. Default precision specifier: Defined byNumberFormatInfo.NumberDecimalDigits. | 1234.567 ("N", en-US) -> 1,234.57 1234.567 ("N", ru-RU) -> 1 234,57 1234 ("N1", en-US) -> 1,234.0 1234 ("N1", ru-RU) -> 1 234,0 -1234.56 ("N3", en-US) -> -1,234.560 -1234.56 ("N3", ru-RU) -> -1 234,560
"P" or "p" | Percent | Result: Number multiplied by 100 and displayed with a percent symbol. Supported by: All numeric types. Precision specifier: Desired number of decimal places. Default precision specifier: Defined by NumberFormatInfo.PercentDecimalDigits. | 1 ("P", en-US) -> 100.00 % 1 ("P", fr-FR) -> 100,00 % -0.39678 ("P1", en-US) -> -39.7 % -0.39678 ("P1", fr-FR) -> -39,7 %
"R" or "r" | Round-trip | Result: A string that can round-trip to an identical number. Supported by: Single, Double, and BigInteger. Precision specifier: Ignored. | 123456789.12345678 ("R") -> 123456789.12345678 -1234567890.12345678 ("R") -> -1234567890.1234567
"X" or "x" | Hexadecimal | Result: A hexadecimal string. Supported by: Integral types only. Precision specifier: Number of digits in the result string. | 255 ("X") -> FF -1 ("x") -> ff 255 ("x4") -> 00ff -1 ("X4") -> 00FF
Any other single character | Unknown specifier | Result: depending on the usage context |

Table 1: standard numeric format strings

Format specifier | Name | Description | Examples
"0" | Zero placeholder | Replaces the zero with the corresponding digit if one is present; otherwise, zero appears in the result string. | 1234.5678 ("00000") -> 01235 0.45678 ("0.00", en-US) -> 0.46 0.45678 ("0.00", fr-FR) -> 0,46
"#" | Digit placeholder | Replaces the "#" symbol with the corresponding digit if one is present; otherwise, no digit appears in the result string. | 1234.5678 ("#####") -> 1235 0.45678 ("#.##", en-US) -> .46 0.45678 ("#.##", fr-FR) -> ,46
"." | Decimal point | Determines the location of the decimal separator in the result string. | 0.45678 ("0.00", en-US) -> 0.46 0.45678 ("0.00", fr-FR) -> 0,46
"," | Group separator and number scaling | Serves as both a group separator and a number scaling specifier. As a group separator, it inserts a localized group separator character between each group. As a number scaling specifier, it divides a number by 1000 for each comma specified. | Group separator specifier: 2147483647 ("##,#", en-US) -> 2,147,483,647 2147483647 ("##,#", es-ES) -> 2.147.483.647 Scaling specifier: 2147483647 ("#,#,,", en-US) -> 2,147 2147483647 ("#,#,,", es-ES) -> 2.147
"%" | Percentage placeholder | Multiplies a number by 100 and inserts a localized percentage symbol in the result string.. | 0.3697 ("%#0.00", en-US) -> %36.97 0.3697 ("%#0.00", el-GR) -> %36,97 0.3697 ("##.0 %", en-US) -> 37.0 % 0.3697 ("##.0 %", el-GR) -> 37,0 %
"‰" | Per mille placeholder | Multiplies a number by 1000 and inserts a localized per mille symbol in the result string. | 0.03697 ("#0.00‰", en-US) -> 36.97‰ 0.03697 ("#0.00‰", ru-RU) -> 36,97‰
"E0" "E+0" "E-0" "e0" "e+0" "e-0" | Exponential notation | If followed by at least one 0 (zero), formats the result using exponential notation. The case of "E" or "e" indicates the case of the exponent symbol in the result string. The number of zeros following the "E" or "e" character determines the minimum number of digits in the exponent. A plus sign (+) indicates that a sign character always precedes the exponent. A minus sign (-) indicates that a sign character precedes only negative exponents. | 987654 ("#0.0e0") -> 98.8e4 1503.92311 ("0.0##e+00") -> 1.504e+03 1.8901385E-16 ("0.0e+00") -> 1.9e-16
\ | Escape character | Causes the next character to be interpreted as a literal rather than as a custom format specifier. | 987654 ("\###00\#") -> #987654#
'string' "string" | Literal string delimiter | Indicates that the enclosed characters should be copied to the result string unchanged. | 68 ("# ' degrees'") -> 68 degrees 68 ("#' degrees'") -> 68 degrees
; | Section separator | Defines sections with separate format strings for positive, negative, and zero numbers. | 12.345 ("#0.0#;(#0.0#);-\0-") -> 12.35 0 ("#0.0#;(#0.0#);-\0-") -> -0- -12.345 ("#0.0#;(#0.0#);-\0-") -> (12.35) 12.345 ("#0.0#;(#0.0#)") -> 12.35 0 ("#0.0#;(#0.0#)") -> 0.0 -12.345 ("#0.0#;(#0.0#)") -> (12.35)
Other | All other characters | The character is copied to the result string unchanged. |

Table 2: Custom numeric format strings


Fine technical details

Last edited: 10/5/2017 11:51:44 AM

AS every software system Redbex also has to deal with some fundamental concepts of information technology, this chapter describes some real technical but none the less important details.


Handling of double values

Last edited: 10/5/2017 11:51:10 AM

To understand computations done by a computer and therefore also to understand the computations performed by the Redbex Application Server it is sometimes useful to know some basic rules of how a computer handles the comparison of double values.

While the result of integer computations can usually be represented in computer systems using 32 or 64 bits of memory the representation of floating point numbers that result from computations may produce quantities that cannot be represented exactly in computer systems. The result of a floating point calculation is therefore often rounded to fit into a finite representation within a computer system. For example the quantity 0.1 cannot be represented exactly in a computer system since its binary representation is periodic.

The Application Server makes extensive use of the double (64bit) or float (32bit) floating point representations for floating point numbers. Wherever numbers that are represented in either one of these representations are used in calculations the Application Server has do deal with the rounding error.

In most cases the user will not see any effect of this internal rounding and the system will nicely do all the calculation work and will deliver reliable calculation results. However in some border cases and mostly when comparing two double values you might experience results that are founded in the rounded internal representation.

The Application Server tries to deal with this insufficiency by handling comparisons of double values using a (very small) error constant. Table 1 shows examples of comparisons done with an error constant. Wherever necessary this documentation will therefore specify the error constant used.

Mathematical operation | Application Server operation
A > B .... | A - e > B
A < B | A + e > B
A = B | | A - B | > e

Table 1: Comparison of double values with an error constant


Null

Last edited: 10/5/2017 11:51:30 AM

In many places the Application Server will work with NULL. e.g. a property in a property structure instance can be NULL.

By itself NULL is not a value. It is a state indicating that an item's value is unknown or nonexistent. It is not zero or blank or an “empty string” and it does not behave like any of these values. For understanding NULL you should stick to the following simple definition: NULL means unknown.


Handling of files

Last edited: 10/5/2017 11:51:22 AM

In several places the Application Server has to deal with files as data input or data output. E.g. data might be imported from files or reports are stored as files. Following chapters describe how the Application Server handles files.


File storage

Last edited: 10/5/2017 11:51:18 AM

All files that the Application Server stores, e.g. as data for instances of a property of type binary value or a created report, undergo a thorough inspection before they are stored. The Application Server tries to extract structured information from the files that can then be used for searching, previewing etc.

Basic file properties

For each file stored by the Application Server the file name, and the size of the file are extracted and stored as separate meta data.

Mime type

The Application Server analyzes the stored files for their Internet Media Type (MIME-Type) and stores this information along with the file. The analysis of mime types is based purely on the inspection of the file extension.

Preview image

If possible the Application Server creates a preview image whenever a new file is stored. Preview images are low resolution (96 x 96 pixel) raster images that give a first impression of the file contents without loading the binary data itself. For mime types listed in table 1 the Application Server creates those previews natively i.e. without dependency on some external software.

For files of all other media types the Application Server relies on the Windows operating system's abilities to create preview images for files. For non natively supported media types it is therefore depending on your operating system installation and configuration if a preview image can be created.

Media type | Media subtype
image | gif, jpeg, png, tiff, bmp

Table 1: Media types for which the Application Server supports preview generation natively

File meta data

Files of some media types can contain information about themselves as so called file meta data, examples for this meta data are EXIF data stored with image files or IDv3 stored with audio files. The Application Server supports the extraction of meta data from some file types as listed in table 12 Depending on the meta data type the Application Server does not necessarily extract all meta data.

Meta data type | Media type | Media subtype
EXIF | image | jpeg, tiff

Table 2: Supported meta data types and media types from which they can be extracted


Output files

Last edited: 12/1/2017 2:02:48 PM

Processes in the Application Server types that generate files as output (like the creation of reports) will store these files in the Output files. Output files is a personal storage place for each user. The output files are structured in folders that contain files.


File depot

Last edited: 10/5/2017 11:51:18 AM

The Application Server provides a personal file depot for each user. The file depot is a simple storage space on the Application Server that stores files for later use. A user can upload any file to his personal file depot.

Whenever the Application Server needs files as input data for a specific operation the user can advice the Application Server to take this file from the user's file depot.The Application Server will then use the file from the depot and will remove it from the depot afterwards.

Files in the file depot of a specific user are only visible and accessible for that user.


Time spans

Last edited: 10/5/2017 11:51:44 AM

Whenever it comes to defining a time span, i.e. a interval of time the Application Server supports two different methods of doing so. The static time span that is defined simply with a start and an end time and the dynamic time span that allows definition of a time span based on some rules and the current date and time.


Static time span

Last edited: 10/5/2017 11:51:42 AM

A static time span is the definition of a time span based on a lower boundary timestamp and an upper boundary timestamp. Additionally a static time span defines separately for the lower and the upper time span if the boundary timestamps are part of the interval or not (c.f. closed interval, open interval, half-open interval) See table 1 for effects of boundary inclusion.

The lower and upper value of a static time span can be empty to define an 'infinite' lower or upper boundary. See Table 2 for effects of empty boundaries.

Lower boundary included | Upper boundary included | Effective time span
yes | yes | 2011-01-01 00:00:00.0000000 to 2012-01-01 00:00:00.0000000
yes | no | 2011-01-01 00:00:00.0000000 to 2011-12-31 23:59:59.9999999
no | yes | 2011-01-01 00:00:00.0000001 to 2012-01-01 00:00:00.0000000
no | no | 2011-01-01 00:00:00.0000001 to 2011-12-31 23:59:59.9999999

Table 1: Effect of inclusion or non-inclusion of interval boundaries for example lower boundary = 2011-01-01 00:00:00.0000000, upper boundary = 2012-01-01 00:00:00.0000000

Lower boundary | Upper boundary | Effective time span
2011-01-01 00:00:00.0000000 | 2012-01-01 00:00:00.0000000 | 2011-01-01 00:00:00.0000000 to 2012-01-01 00:00:00.0000000
2011-01-01 00:00:00.0000000 | empty | 2011-01-01 00:00:00.0000000 to 9999-12-31 23:59:59.9999999
empty | 2012-01-01 00:00:00.0000000 | 0001-01-01 00:00:00.0000000 to 2012-01-01 00:00:00.0000000
empty | empty | 0001-01-01 00:00:00.0000000 to 9999-12-31 23:59:59.9999999

Table 2: Effect of empty boundaries in a static time span definition


Dynamic time span

Last edited: 10/5/2017 11:51:14 AM

A dynamic time span is the definition of a time span (a lower value and a upper value) based on the current point in time and rules that derive a lower timestamp and an upper timestamp from the current point in time.

The effective time span is evaluated on access i.e. when it is used. When a dynamic time span is evaluated, the current timestamp is first transformed into a base timestamp using given adjustment rules and then the lower and upper boundary of the time span is calculated based on this base timestamp using the specified offset values.

Definition of a dynamic time span

A dynamic time span definition specifies how the current timestamp is adjusted to get the base time stamp

1.Base timestamp adjustment part: Defines which part of the date time is adjusted, options are: None, Minute, Hour, Day, Week, Month or Year

2.Basic timestamp adjustment type : Defines if the how the current timestamp adjusted to the part defined with adjustment part.

3.Lower boundary offset type: Defines the unit of the offset value for the lower boundary. Options are months and time span (days, hours, minutes, seconds)

4.Lower boundary offset value: Value that is subtracted from the basic timestamp to calculate the lower boundary of the dynamic time span. Negative values can be used to dynamically form a lower boundary in the future.

5.Upper boundary offset type: Defines the unit of the offset value for the upper boundary. Options are months and time span (days, hours, minutes, seconds)

6.Upper boundary offset value: Value that is subtracted from the basic timestamp to calculate the upper boundary of the dynamic time span. Negative values can be used to dynamically form a upper boundary in the future.

Adjustment of the current timestamp to a basic timestamp

The basic timestamp is the timestamp on which the calculation of the lower and upper boundary of the dynamic time span are based. The basic timestamp itself is derived from the date and time when the dynamic time span was accessed by using following adjustment types and adjustment part.

Adjustment methods

·None: base timestamp becomes current timestamp

·Round: The current timestamp is rounded according to the adjustment type. . E.g. If the current timestamp is 2015-01-12 21:15:02.12, the adjustment type is round and the adjustment part is hours the resulting base timestamp would be 2015-01-12 21:00:00.00.

·Ceiling: The current timestamp is set to the next full unit according to the adjustment type. E.g. If the current timestamp is 2015-01-12 21:15:02.12, the adjustment type is ceiling and the adjustment part is month the resulting base timestamp would be 2015-02-01 00:00:00.00.

·Floor: The current timestamp is being set to the previous full unit according to the adjustment type. E.g. If the current timestamp is 2015-01-12 21:15:02.12, the adjustment type is floor and the adjustment part is minutes the resulting base timestamp would be 2015-01-12 21:15:00.00.

Adjustment parts

·Year: Year part of the date will be adjusted. Rounding a year checks today to which half does it belong. If today belongs in first half of the year then use current year, else use beginning of next year.

·Month: Adjust the month part. Floor and ceiling simply uses beginning of current and next month respectively. While round checks if today is in first half of the current month, if true then rounds to the beginning of current month. Otherwise use the beginning of next month.

·Week: When adjusting the current time span using week as adjustment type the system always uses first day of the week based on the user's culture.

·Day: Floor and ceiling moves the time stamp to the beginning of today and the beginning to tomorrow. Rounding checks if the half of the day has passed, if so use beginning of tomorrow, else use beginning of today.

·Hour: Floor and ceiling an hour works as expected(beginning of current and next hour). Rounding checks if half of the current hour is passed already, if so use next hour. Otherwise use the beginning of current hour.

·Minute: Adjusting the minutes adjust the minute part of the time. If floored uses the beginning of current minute, ceiling uses the beginning of next minute. Rounding check the seconds, If 30 seconds has passed in the current minute, use the beginning of next minute. If current time is within the first 30 second, then system uses the beginning of current minute.

Calculation of the lower and upper time span boundary

Based on the basic timestamp the system computes the lower and upper boundary of the time span using the given offset type and offset offset values. The offset values are subtracted from the basic timestamp therefore to specify lower or upper boundaries in the future negative offsets have to be used.

The calculation of a dynamic time span will internally create a static time span with non-empty lower and upper boundaries and lower and upper boundary included in the time span.


Text templates

Last edited: 10/5/2017 11:51:44 AM

The Application Server makes use of text templates in various places. Text templates are blueprints of text that can include variables, filters and other expressions. When a text template gets processed by the text template engine it will parse and evaluate markup text found in the text template and will render an output text.

Example: the template Hello {{name}} will be processed into Hello World if the context in which the template is processed provides a the value World for the markup {{name}}.

Which markups can be parsed by the template engine depends on the context in which the template is used.


Designing text templates

Last edited: 10/5/2017 11:51:18 AM

A text template consist of normal text and specially designated markup elements. There are two types of markup that can be included in a template: Output markups and Tag markups. These markup elements will be processed by the template engine. Output markups will produce some text, tag markups are used for additional functionality like conditional output, looping through collections etc.

Dear {% if user.Gender == 'male' %}Mr.{% elsif user.gender == 'female' %}Mrs.{% endif %} {{user.last_name},

Thanks for using {{productname}}!

Listing 1: An exemplary Text Template

Creted by {%if CurrentUser.Gender == 'Male'%}Mr.{%else%}Mrs.{% endif %} {{CurrentUser.FirstName}} {{CurrentUser.LastName | capitalize}} on {{CurrentDateTime | cdate: "dddd dd.mm.yyyy", "bn-BD"}}

Listing 2: A text template as it might be used for the footer line of a chart presentation


Output markup

Last edited: 10/5/2017 11:51:30 AM

The syntax for an Output markup (which may resolve to text) is {{ OutputMarkupExpression }}. The Output markup expression is a string that instructs the template engine how process this part of the text template.

Output markup expressions can consist of markup variables, string or integer literals and filters. String literals are put in single quotes.

When the text template is rendered the whole markup string (including the braces) will be replaced by the text generated by the template engine. If a markup expression cannot be parsed by the template engine the markup will be replaced with an empty string or by an error message.

Table one shows some examples for output markup expressions.

Text Template | Notes
Hello {{FirstName}} | This template uses a markup with expression FirstName. This expression will be treated as variable by the template engine. If the context in which the template is executed provides a value for a the variable FirstName the markup will be replaced with this value.
Hello {{user.name}} | This template uses a markup with expression name user.name. This expression refers to an object with name user and a property of that object called name. If the context in which the template is executed provides an object with name user and if that object has a property name the markup will be replaced with the value of that property.
Hello {{ 'SomeName' }} | The '' in the markup expression advice the engine to threat the expression as string. Therefore the result after rendering this markup would be Hello SomeName.

Table 1: Simple examples for output markup expressions


Markup variables

Last edited: 10/5/2017 11:51:28 AM

Output markup expressions can include variables. Variables can point to values of simple types like integer, double, date&time etc., can point to markup classes with properties or can point to a collection o other markup variables.

In markup expressions variables of simple type are referenced by their name, the properties of an object are referenced by <variablename>.<propertyname>, members of a collection are referenced by their index. See Table2 for examples.

Markup expression

Result

{{VariableA}}

If VariableA points to a simple type this expression will be replaced by the value of the simple type.

If VariableA points to a class the expression will be replaced by a textual representation of all properties of that class.

If VariableA points to a collection this expression will be replaced by an empty string

{{VariableB.Property1}}

If VariableB points to a class and that class has a property of a simple type named Property1 the expression will be replaced by a textual representation that property.

If VariableB points to a class and that class has a property of named Property1 that is itself a class the expression will be replaced by a textual representation of all properties of that class.

{{VariableC[0].Property1}}

If VariableC points to a collection and members of that collection have a property named Property1 this expression will be replaced by the value of Property1 of the first element in the collection.

Note that the collection index is zero-based.

Table 2: Examples for the usage of markup variables.

Names of variables and properties are case sensitive.

There is a set of common variables available in every text template, see chapter Common markup variables for a complete listing of those variables. The context in which a template is executed may define more variables. Refer tot he documentation of the context for details.


Filters

Last edited: 11/21/2017 6:39:26 AM

Output markup takes filters. Filters are simple methods. The first parameter is always the output of the left side of the filter. The return value of the filter will be the new left value when the next filter is run. When there are no more filters, the template will receive the resulting string. Listing 1 shows some example of using filters in markup expressions.

Filter names are case sensitive (all filter names are lower case). Some filters take arguments, arguments are added after the filter name separated by colon. Multiple arguments are separated by a comma.

Hello {{ 'tobi' | upcase }}

Hello tobi has {{ 'tobi' | size }} letters!

Hello {{ 'now' | cdate: "%Y %h" }}

Listing 1: Markup expressions using filters

Filters

Filter

Notes

append

Append a string e.g. {{ 'foo' | append:'bar' }} results in foobar

capitalize

Capitalize words in the input sentence

cdate:<formatstring>,<cultureName>

Reformat a date. formatstring is a date format string, culture name is any valid culture name E.g. en-US . If culture name is left empty the User's Application server culture will be used.

{{ SomeDateVariable | cdate:"MMMM dd, yyyy", "en-US" }}

cnumber:<formatstring>,<cultureName>

Reformat a numeric value. formatstring is a numeric format string, culture name is any valid culture name E.g. en-US . If culture name is left empty the User's Application server culture will be used.

{{ SomeNumericVariable | cnumber:"e", "en-US" }}

divided_by

Division e.g. {{ 10 | divided_by:2 }} results in 5

downcase

Convert an input string to lowercase

escape

Escape a string

escape_once

Returns an escaped version of html without affecting existing escaped entities

first

Get the first element of the passed in array

getvalidfilename

Replaces characters in a string that are not valid characters for files and directories in a windows file system. If a replacement character is passed and if that character is a valid character for files an directories this replacement is used else then underscore character is used as replacement.

getwordno: <delimiter>, <number>

Gets a specific word from a string.

Eg:

{{ 'foo1 bar1 foo2 bar2' | getwordno: ' ', 1 }} results in bar1 (note: word number is given 0-based)

last

Get the last element of the passed in array

map

Map/collect an array on a given property

minus

Subtraction e.g. {{ 4 | minus:2 }} results in 2

modulo

Remainder, e.g. {{ 3 | modulo:2 }} results in 1

newline_to_br

Replace each newline (\n) with html break

padleft

Returns a string from an expression, padded with spaces or characters to a specified length on the left side.

e.g. {{ 'abc' | padleft:'X', 5}} returns XXabc

{{ '123' | padleft: '0', 5}} returns 00123

{{ '123' | padleft: '0', 2}} returns 123

Padleft works with strings as well as with numbers. If the padding character is not given a space will be used, if the length is not given a length of 1 is assumed.

plus

Addition e.g. {{ '1' | plus:'1' }} results in '11', {{ 1 | plus:1 }} results in 2

prepend

Prepend a string e.g. {{ 'bar' | prepend:'foo' }} results in foobar

remove

Remove each occurrence e.g. {{ 'foobarfoobar' | remove:'foo' }} results in barbar

remove_first

Remove the first occurrence e.g. {{ 'barbar' | remove_first:'bar' }} results in bar

replace

Replace each occurrence e.g. {{ 'foofoo' | replace:'foo','bar' }} results in barbar

replace_first

Replace the first occurrence e.g. {{ 'barbar' | replace_first:'bar','foo' }} results in foobar

size

Return the size of an array or string

sort

Sort elements of the array

split

Split a string on a matching pattern e.g. {{ "a~b" | split:"~" }} results in ['a','b']

strip_html

Strip html from string

strip_newlines

Strip all newlines (\n) from string

times

Multiplication e.g {{ 5 | times:4 }} results in 20

truncate:<maxLength>

Truncate a string down to maxLength characters. If the text is longer than the given number of characters the text is truncated and an ellipsis is added to the end of the string.

E.g. {{ 'AVeryLongFileName' | truncate: 8}} results in AVery...

truncatebeginningend: <beginning>, <end>

Truncates the given number of characters from the beginning of a string and then the given number of characters from the end of the string and returns the result.

E.g. {{ '40_000982_01' | truncatebeginningend: 3, 3}} results in 000982

truncatewords:<maxWords>

Truncate a string down to maxWords words

upcase

Convert an input string to uppercase

Table 2: Available filters


General output markups

Last edited: 10/5/2017 11:51:10 AM

This chapter lists variables (which can be primitives, classes and collections of primitives or classes) available for output markup with any text template in Redbex. The context in which the text template is used might provide additional variables. Refer to the documentation of the context for details.

Variable Name | Variable type | Description
GlobalSetting | Class | The GlobalSetting exposes the values of some Global Settings.
License | Class | The License object exposes some properties of the currently loaded license.
Support | Class | The Support object exposes contact information for technical support. This information is read from the currently loaded license. The values are therefore set by the distributor of the license.
Branding | Class | The Branding object exposes data that is used for branding Redbex. Branding information is read from the currently loaded license and is therefore provided by the distributor of the license.
Product | Class | The Product object exposes some information about the Redbex software product.
Instance | Class | The Instance object exposes details about the currently loaded instance configuration.
CurrentUser | Class | The User object exposes details about the user executing the text template.
CurrentDateTime | Primitive | The current date & time (when the template is processed). Use filters to format the date& time value according to your needs.

Table 1: Markup variables available with all text templates

GlobalSetting Class

Variable name | Variable type | Description
OperatorName | Primitive | Value of the respective global setting.
OperatorWebPage | Primitive
OperatorAdministratorEmail | Primitive
OperatorAdministratorTelephoneNumber | Primitive
ApplicationServerAddress | Primitive
SmtpAllowAttachments | Primitive
DomainName | Primitive

Table 2: Properties of the GlobalSetting markup class.

License Class

Variable name | Variable type | Description
LicenseeName | Primitive | Information about the currently loaded license
LicenseeContactDetails | Primitive
LicenseEmailAddress | Primitive
ProductKey | Primitive

Table 3: The License, Support and Branding classes expose data read from the currently loaded license.

Support Class

Variable name | Variable type | Description
SupportOrganization | Primitive | Product support information
SupportContact | Primitive
SupportTelephoneNumber | Primitive
SupportEmailAddress | Primitive
SupportWebPage | Primitive
SupportDescription | Primitive

Table 4: The License, Support and Branding classes expose data read from the currently loaded license.

Branding Class

Variable name | Variable type | Description
OrganizationName | Primitive | Branding organization name

Table 5: The License, Support and Branding classes expose data read from the currently loaded license.

Product Class

Variable name | Variable type | Description
Name | Primitive | Information about the product producer
Producer | Primitive
ProducerContact | Primitive
Copyright | Primitive
WebPage | Primitive | Redbex web page of Pöyry Infra GmbH
DocumentationWebPage | Primitive | Web page where the documentation of Redbex can be viewed.
DownloadWebPage | Primitive | Web page where the components of the Redbex system can be downloaded.

Table 6: The Product class exposes some general facts about Redbex

Instance Class

Variable name | Variable type | Description
InstanceIdentifier | Primitive | Name of the running Application Server instance
Protocols | Collection | A collection of objects of class Protocol describing the protocols available on this instance of the Application Server

Table 7: Miscellaneous variables

User Class

Property | Variable type | Description
Username | Primitive | Details of the currently accessing user.
FirstName | Primitive
MiddleName | Primitive
LastName | Primitive
Id | Primitive
CellNumber | Primitive
PhoneNumber | Primitive
EmailAddress | Primitive
Address | Primitive
Company | Primitive
Position | Primitive
Gender | Primitive | A string that defines the gender of the user possible values are: ·Male ·Female ·Undefined
FormattedUserNameSystem | Primitive | Nicely formatted name of the currently accessing user. Includes username first name, middle name and last name
FormattedUserNameSignature | Primitive | Nicely formatted name of the currently accessing user. Includes pre-nominal letters, post-nominal letters, first name, middle name and last name
AuthenticationType | Primitive | A string that defines which authentication type is used for this user. Possible values are: ·ApplicationServer ·AdLdap ·AdLdaps

Table 8: The User class that exposes properties a specific Redbex user.

Protocol Details Class

Property | Variable type | Description
Protocol | Primitive | Name of the protocol
Port | Primitive | Port configured for this protocol
Enabled | Primitive | Specifies if this protocol is enabled

Table 9: The protocol class exposing details about a specific connection protocol.


Tag markup

Last edited: 10/5/2017 11:51:42 AM

The syntax for Tag markup is {% matched pairs of curly brackets and percent signs %} .Tag markup are used for the logic in your template and is not resolved to text, table 1 lists the supported tags:

Markup | Notes
assign | Assigns some value to a variable
capture | Block tag that captures text into a variable
case | Block tag, its the standard case...when block
comment | Block tag, comments out the text in the block
cycle | Cycle is usually used within a loop to alternate between values, like colors or DOM classes.
for | For loop
if | Standard if/else block
include | Includes another template; useful for partials
raw | temporarily disable tag processing to avoid syntax conflicts.

Table 1: Available tag markups

Comments

Comment is the simplest tag. It just swallows content.

We made 1 million dollars {% comment %} in losses {% endcomment %} this year

Listing 1: Comments in Text templates

Raw

Raw temporarily disables tag processing. This is useful for generating content (eg, Mustache, Handlebars) which uses conflicting syntax.

{% raw %}

In Handlebars, {{ this }} will be HTML-escaped, but {{{ that }}} will not.

{% endraw %}

Listing 2: Raw tag in text templates

If / Else

if / else should be well-known from any other programming language. This tag allows you to write simple expressions in the if or unless (and optionally, elsif and else) clause:

{% if user %}

Hello {{ user.name }}

{% endif %}

Listing 3: Example for conditional processing

# Same as above

{% if user != null %}

Hello {{ user.name }}

{% endif %}

Listing 4: Example for conditional processing

{% if user.name == 'tobi' %}

Hello tobi

{% elsif user.name == 'bob' %}

Hello bob

{% endif %}

Listing 5: Example for conditional processing

{% if user.name == 'tobi' or user.name == 'bob' %}

Hello tobi or bob

{% endif %}

Listing 6: Example for conditional processing

{% if user.name == 'bob' and user.age > 45 %}

Hello old bob

{% endif %}

Listing 7: If / Else example

{% if user.name != 'tobi' %}

Hello non-tobi

{% endif %}

Listing 8: Example for conditional processing

# Same as above

{% unless user.name == 'tobi' %}

Hello non-tobi

{% endunless %}

Listing 9: If / Else example

# Check for the size of an array

{% if user.payments == empty %}

you never paid !

{% endif %}

{% if user.payments.size > 0 %}

you paid !

{% endif %}

Listing 10: Example for conditional processing

{% if user.age > 18 %}

Login here

{% else %}

Sorry, you are too young

{% endif %}

Listing 11: Example for conditional processing

# array = 1,2,3

{% if array contains 2 %}

array includes 2

{% endif %}

Listing 12: Example for conditional processing

# string = 'hello world'

{% if string contains 'hello' %}

string includes 'hello'

{% endif %}

Listing 13: Example for conditional processing

Case Statement

If you need more conditions, you can use the case statement. Listing 14 shows the syntax for case statements, Listing 15 shows a usage example.

{% case condition %}

{% when 1 %}

hit 1

{% when 2 or 3 %}

hit 2 or 3

{% else %}

... else ...

{% endcase %}

Listing 14: Case statement syntax

{% case template %}

{% when 'label' %}

// {{ label.title }}

{% when 'product' %}

// {{ product.vendor | link_to_vendor }} / {{ product.title }}

{% else %}

// {{page_title}}

{% endcase %}

Listing 15: Case statement example

Cycle

Often you have to alternate between different colors or similar tasks. Text templates have built-in support for such operations, using the cycle tag. Listing 16 shows an example of the cycle tag, listing 17 the result if this tag rendered.

{% cycle 'one', 'two', 'three' %}

{% cycle 'one', 'two', 'three' %}

{% cycle 'one', 'two', 'three' %}

{% cycle 'one', 'two', 'three' %}

Listing 16: Case statement example

one

two

three

one

Listing 17: Result of template shown in listing 16

If no name is supplied for the cycle group, then it's assumed that multiple calls with the same parameters are one group.

If you want to have total control over cycle groups, you can optionally specify the name of the group. This can even be a variable. See Listing 18 for a template example and Listing 19 for the result of this template.

{% cycle 'group 1': 'one', 'two', 'three' %}

{% cycle 'group 1': 'one', 'two', 'three' %}

{% cycle 'group 2': 'one', 'two', 'three' %}

{% cycle 'group 2': 'one', 'two', 'three' %}

Listing 18: Example of cycles with group names

one

two

one

two

Listing 19: Result of processing template in listing 18

For loops

Text templates allow for loops over collections:

{% for item in array %}

{{ item }}

{% endfor %}

Listing 20: syntax of for loops

When iterating a hash, item[0] contains the key, and item[1] contains the value:

{% for item in hash %}

{{ item[0] }}: {{ item[1] }}

{% endfor %}

Listing 21: For loop example

During every for loop, the following helper variables are available for extra styling needs:

forloop.length # => length of the entire for loop

forloop.index # => index of the current iteration

forloop.index0 # => index of the current iteration (zero based)

forloop.rindex # => how many items are still left?

forloop.rindex0 # => how many items are still left? (zero based)

forloop.first # => is this the first iteration?

forloop.last # => is this the last iteration?

Listing 22: Variables available in for loops

There are several attributes you can use to influence which items you receive in your loop

limit:int lets you restrict how many items you get. offset:int lets you start the collection with the nth item.

# array = [1,2,3,4,5,6]

{% for item in array limit:2 offset:2 %}

{{ item }}

{% endfor %}

# results in 3,4

Listing 23: Limiting iterated items

Reversing the loop:

{% for item in collection reversed %} {{item}} {% endfor %}

Listing 24: Example for reversed for loop

Instead of looping over an existing collection, you can define a range of numbers to loop through. The range can be defined by both literal and variable numbers:

# if item.quantity is 4...

{% for i in (1..item.quantity) %}

{{ i }}

{% endfor %}

# results in 1,2,3,4

Listing 25: Defining loop collection on the fly

Variable Assignment

You can store data in your own variables, to be used in output or other tags as desired. The simplest way to create a variable is with the assign tag, which has a pretty straightforward syntax:

{% assign name = 'freestyle' %}

{% for t in collections.tags %}{% if t == name %}

<p>Freestyle!</p>

{% endif %}{% endfor %}

Listing 26: Assigning variables

Another way of doing this would be to assign true / false values to the variable:

{% assign freestyle = false %}

{% for t in collections.tags %}{% if t == 'freestyle' %}

{% assign freestyle = true %}

{% endif %}{% endfor %}

{% if freestyle %}

<p>Freestyle!</p>

{% endif %}

Listing 27: Assigning variables

If you want to combine a number of strings into a single string and save it to a variable, you can do that with the capture tag. This tag is a block which "captures" whatever is rendered inside it, then assigns the captured value to the given variable instead of rendering it to the screen.

{% capture attribute_name %}{{ item.title | handleize }}-{{ i }}-color{% endcapture %}

<label for="{{ attribute_name }}">Color:</label>

<select name="attributes[{{ attribute_name }}]" id="{{ attribute_name }}">

<option value="red">Red</option>

<option value="green">Green</option>

<option value="blue">Blue</option>

</select>

Listing 28: Assigning variables


Action log

Last edited: 11/8/2017 9:31:34 AM

In many cases the Application Server logs details about the processing of some request to so called action logs.

An action log contains structured information that is intended for the human reader. The action log can be sent back to clients as part of the result of a request. An action log consists of action log entries. Table 1 describes the information contained in an action log entry. Figure 1 shows an example of an action log.

Item | Description
Entry No | Sequential number of the entry
Timestamp | The timestamp when this entry was created
Process ID | Id of the process / thread that wrote this entry.
Entry text | The textual information. This textual information is always in English.
Level | The action log can form hierarchies of entries. The level describes the hierarchy level of a specific entry.

Table 1: Information contained within an action log entry

Figure 1: Example of an action log. This action log was sent to the client as a response to the login.


UConfiguration

Last edited: 12/14/2017 8:00:54 AM

UConfigurations (short for universal configuration) are used in many places to define multiple aspects of objects on the Application Server e.g. the layout of a chart or the settings of a calculation algorithm in a calculated feature.

UConfigurations are structured sets of settings defined by the Application Server. Clients like the Smart Client usually use the same dynamic user interface for all configurations (e.g. a property grid) This gives the users a common and standardized way of configuring different things on the Application Server.

The building blocks of UConfigurations are Settings and Groups. Groups can contain one or more settings and can contain sub-groups and can therefore form a hierarchical structure. Figure 1 shows a schematic example of a configuration including settings and groups.

Figure 1: Example of a hierarchically structured UConfiguration.

Each setting has a name and a description that further describes the use or effect of the setting. Each setting is of a specific setting type (both provided in by the Application Server in all supported server languages). Each configuration setting is of a specific setting type that defines the data that can be stored with this configuration setting. Table 1 shows the available setting types.

Each setting type has its own possibilities to validate the data that can be stored with the type can define a default value for the setting. A UConfiguration might also define validation rules for the whole UConfiguration, i.e. rules that check for specific constellations of Setting-Values.

While the UConfiguration will always be checked for violations of validations rules of settings or the whole UConfiguration the client you use to edit a UConfiguration does not necessarily validate the UConfiguration rules. In other words it might be possible to store invalid UConfigurations. However when a UConfiguration is used by the Application Server it will first be validated there, which includes the validation of each setting and the validation of the whole configuration. At that point in time invalid settings will cause the operation using the UConfiguration to fail.

The settings in a UConfiguration might have default values.

Setting may also define hints for clients (like the Smart Client) how to display and edit values of this setting. E.g. the UConfiguration might contain a hint that a specific setting of type text shall be displayed in a way that multi-line text can be entered.

Setting type

Notes

Numeric

Can store numerical data (doubles).

The values can be restricted by a value range. Numeric settings might allow null, i.e. might be left undefined.

For display and edit purposes the setting can include definitions for the number of integer and decimal places that can be entered.

Boolean

Can store true or false.

This setting can never null.

Text

Can store any Unicode text.

The setting can restrict the length (minimum and maximum) of the text and the usage of line breaks (allowed or not allowed). A text configuration setting might also restrict the text to a specific pattern given as regular expression.

Date&Time

Can store a date&time value including time offset and fractional seconds.

The setting can restrict the range of valid date&time values (minimum and maximum value).

Settings of this type might allow null, i.e. might be left undefined.

For display and edit purposes the setting defines the precision of the time, i.e. how many places for fractional seconds are shown.

Time span

Can store a time span value. The setting can restrict the range of valid time spans with a minimum and maximum.

Settings of this type might allow null, i.e. might be left undefined.

For display and edit purposes the setting can include a definition for the decimal places that can be entered (fractional seconds)

Enumeration

Stores the id of a specific element that is member of a specified list of elements.

Clients usually present these settings as combo boxes.

Multi-select enumeration

Stores id-s of a multiple elements that are all member of a specified list of elements.

The setting can restrict the number of elements that can be selected (minimum and maximum)

Axis

Stores a reference to a specific axis.

Settings of this type might allow null, i.e. might be left undefined.

Axis reference system

Stores a reference to a specific axis reference system.

Settings of this type might allow null, i.e. might be left undefined.

Color

Stores an RGB color.

Settings of this type might allow null, i.e. might be left undefined.

Domain

Stores a reference to d domain

Settings of this type might allow null, i.e. might be left undefined.

Feature

Stores a reference to a feature

Settings of this type might allow null, i.e. might be left undefined.

Feature subtype

Stores a reference to a specific feature subtype.

Settings of this type might allow null, i.e. might be left undefined.

Feature type

Stores a reference to a feature type

Settings of this type might allow null, i.e. might be left undefined.

Image

Stores an image.

The maximum size of the image can be restricted.

Settings of this type might allow null, i.e. might be left undefined.

Property

A reference to a property in a property structure

Settings of this type might allow null, i.e. might be left undefined.

Secure string

Stores a string in (synchronously) encrypted form.

Settings of this type might allow null, i.e. might be left undefined.

Presentation template

A reference to a presentation template template

Settings of this type might allow null, i.e. might be left undefined.

View

A reference to a view.

Settings of this type might allow null, i.e. might be left undefined.

Structured data

This setting type is used for storing not single values but data structures containing multiple values (XML).

Table 1: Setting types for settings in UConfigurations


Server feedback messages

Last edited: 11/8/2017 9:31:18 AM

Whenever the client requests a service form the server the response to this request will include a (possibly empty) list of server feedback messages. These messages can give detailed information about the processing of the request and are meant to provide feedback for the human reader.

E.g. if a user requests to list all features that are member of a view but the view definition is not valid the response from the server would be an empty list of features and a server feedback message that indicates that the list is empty because of an invalid view definition.

Each server feedback message consists of a timestamp when the message was created, a feedback code, a message text (expressed in the current session's language) and a severity. Severity levels used in server feedback messages are listed in table 1.

A server feedback message can contain an action log that may provides more detailed information.

Severity | Usage
Informational | Used for feedback messages that are possibly of interest to the user. The message but has no immediate effects on the result of the request
Warning | Used if during processing the Application Server detected a condition that is influencing the result of the request in a way not intended by the user, or for conditions that will likely influence future requests
Severe | Used if during processing a condition was detected that hinders the Application Server from fulfilling the request.

Table 1: Server feedback message severities


Administration

Last edited: 10/5/2017 11:51:04 AM

Following chapters describe details of the Application Server that are mainly of use for System Administrators, i.e. persons who are in charge of configuring the Application Server, optimizing the performance, monitoring the Application Server, and providing a sound environment for the users.


Logging

Last edited: 10/5/2017 11:51:28 AM

The Application Server logs information that might me valuable to administrators or support personnel for tuning performance, tracking down configuration errors and finding reasons for errors. The data logged is logged in form of log messages that contain textual information in English language together some meta-data as described in table 1.

For a persistent record of these log messages the Application Server makes use of a logging engine based on the NLog logging platform. This logging engine allows you to configure where and how log messages are persisted. The Application Server comes with a default configuration for this logging engine that advices the logging engine to persist log data to files in the log directory and to the Windows Event Log (based on certain conditions). If you want to change the logging configuration you can do so by creating an NLog configuration file. You can define your own log targets (where log messages will be persisted) and rules that route log messages to targets based on conditions. The logging engine supports over 20 types of log targets, among them the file system, the Windows event log, email, logentries.com, etc.

Figure 1: The Application Server's log engine

All log data the Application Server issues before the logging engine is started (during the Application Servers start-up process) is logged directly to the Windows Event Log.

Log entry element

Description

Log message source

Source the log message originates from. Possible log message sources are listed in table 2.

Time stamp of logging

Date and time when the log entry was generated

Message

Textual information

Log level

One of the following values

·Trace - very detailed logs, which may include high-volume information such as protocol payloads. This log level is typically only enabled during development

·Debug - debugging information, less detailed than trace, typically not enabled in production environment.

·Info - information messages, which are normally enabled in production environment

·Warn - warning messages, typically for non-critical issues, which can be recovered or which are temporary failures

·Error - error messages

·Fatal - very serious errors

System exception

Exceptions thrown by the system (if any)

Table 1: Data stored in a log message

Log source | Description
Common | Log messages that originate from components used by all other pars of the application Server (see below)
Server | Log messages originating from the Application Servers host process. Especially all Start-up and Shutdown messages.
BusinessLayer | Log messages that originate from the Application Server's business layer. This includes most log messages for the internal logic of the Application Server.
Licensing | Log messages from the licensing engine
ServiceLayer | Log messages from the service layer, including all messages concerning the communication of the Application Server.
DataLayer | Log messages of the data layer, i.e. all messages that deal with data transfer to and from the Application Server Database
Connector | Log messages that originate from connector features.

Table 2: Log message sources


Default logging configuration

Last edited: 10/5/2017 11:51:12 AM

The default configuration for the logging engine persists log data according to the rules described below.

All log entries will be written to a text file named Application Server Main Log <YYYY-MM_DD hh:mm:ss>.txt in the log directory. The file will contain the timestamp, the log level and the message of the log entries. The date encoded in the file name is the date of the first entry in the log file.

All log data with a Log level of Error or Fatal will be written to the Application Server Error Log <YYYY-MM_DD hh:mm:ss>.txt file in the log files directory. The file will contain the timestamp, the log level and the message of the log entries and if the log entry contains an exception also the textual representation of that exception. The date encoded in the file name is the date of the first entry in the log file.

All log data with a severity of Fatal will be written to the Windows Event Log. The event log entry will contain the timestamp, the log level and the message of the log entries and if the log entry contains an exception also the textual representation of that exception.


Custom logging configuration

Last edited: 10/5/2017 11:51:12 AM

If you want to use a custom logging configuration you can do so by creating an NLog configuration file named nlog.config in the Application directory.

On start-up the Application Server will search for an NLog configuration file named nlog.config in the Application directory. If such a file is found, can be read and parsed the Application Server will use that configuration instead of its default configuration.

An nlog.config file is a pure XML file having the <nlog /> element as its root. The use of namespaces is optional. You can use the following elements as sub element to <nlog />. The first two elements from the list are required to be present in all NLog configuration files, the remaining ones are optional and can be useful in advanced scenarios.

·<targets /> – defines log targets/outputs

·<rules /> – defines log routing rules

·<extensions /> – loads NLog extensions from the *.dll file

·<include />– includes external configuration file

·<variable /> – sets the value of a configuration variable

For more information on how to write nLog configuration files please refer to the NLog documentation at http://nlog-project.org/

The Redbex Application Server also supports an NLog Target for logentries.com that can be used to log data in the cloud. To use this online service you will have to create a logentries.com account, which might come at additional cost.


%Text%

Navigation: Application Server > Administration > Logging > Custom logging configuration >

Windows event log target

Last edited: 10/5/2017 11:51:46 AM

You can use the EventLog target in an nlog.config file to write Redbex log messages to the Windows Event log (e.g. if you want to centralize all your logging).

During installation the Setup Program automatically creates an event log source named RedbexApplicationServer that can be used for Redbex event log messages. You may however also create your own event log source if you like. Listing 1 shows an example nlog.config file that writes all log messages to the windows event log of the local machine. Listing 2 shows how you can create your own event log source using the Windows command line tool eventcreate.

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<targets>
<target
name="WindowsEventLogInfo"
xsi:type="EventLog"
layout="REDBEX ${longdate} ${message}"
source="RedbexApplicationServer"
machineName="."
eventId="1"/>
<target name="ColoredConsole" xsi:type="ColoredConsole"/>
</targets>
<rules>
<logger name="*" minlevel="Info" writeTo="WindowsEventLogInfo" />
</rules>
</nlog>

Listing 1: NLog configuration that writes log messages to the windows event log

C:\Windows\system32>eventcreate /ID 1 /L APPLICATION /T ERROR /SO RedbexCustomSource /D "This is a custom event that is for Redbex logging"

Listing 2: Creating an event log source


%Text%

Navigation: Application Server > Administration > Logging > Custom logging configuration >

Logentries.com target

Last edited: 10/5/2017 11:51:28 AM

Additional to the standard targets supported by the NLog platform, the Application Server supports an extension that provides the LogEntriesNLog target which can be used to persist log messages to the online platform logentries.com.

This extension must be specified (loaded) at the beginning of your nlog.config file, see listing 1.

Using an nlog.config file as shown in listing 2 you can then advice the logging engine to persist logging information at logentries.com. Note that logging massively to this target will decrease performance. We recommend to only log important log messages to this target.

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<extensions>
<add assembly="LogentriesNLog"/>
</extensions>

[...]

Listing 1: Loading of the LogentriesNLog extension

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<extensions>
<add assembly="LogentriesNLog"/>
</extensions>
<targets>
<target name="LogentriesTarget"
xsi:type="Logentries"
debug="true"
httpPut="false"
ssl="false"
token="bb61600f-f766-451e-b55f-9204f536a79f"
layout="${date:format=ddd MMM dd} ${time:format=HH:mm:ss} ${date:format=zzz yyyy} ${logger} : ${LEVEL}, ${message}"/>
</targets>
<rules>
<logger name="*" minlevel="Info" writeTo="LogentriesTarget" />
</rules>
</nlog>

Listing 2: An NLog configuration that writes log messages to the logentries.com service


%Text%

Navigation: Application Server > Administration > Logging > Custom logging configuration >

Reloading configuration

Last edited: 10/5/2017 11:51:34 AM

If an NLog configuration file is found the configuration file is read automatically at startup of the Application Server. It may be desirable to change the log levels or other logging configuration during run-time of the Application Server (i.e. without having to restart the Application Server).

By adding the autoReload="true" parameter to the configuration file as shown in listing 1 you can advice the Application Server to monitor changes on the configuration file and reload the configuration as soon as a change is detected.

<nlog autoReload="true">
...
</nlog>

Listing: The autoReload parameter in the nlog.config file


%Text%

Navigation: Application Server > Administration > Logging > Custom logging configuration >

Troubleshooting custom logging configurations

Last edited: 10/5/2017 11:51:44 AM

Since custom logging configurations are pure XML files, many things can go wrong when editing such configuration files.

If the nlog.config file is somehow erroneous or cannot be read (e.g. due to file system permissions) the Application Server will switch to its default configuration and will write an entry to the Windows Event Log, telling you that there was a problem loading the custom configuration file.

If you need more detailed information why a custom log file could not be used by the Application Server you can use the command line switch -l to specify a file where the logging platform shall write more details.


%Text%

Navigation: Application Server > Administration > Logging > Custom logging configuration >

Custom logging configuration examples

Last edited: 1/31/2018 1:09:04 PM

The possibly simplest custom logging configuration is a configuration that disables any logging. While we do not recommend to uses such a configuration it might be useful for debugging purposes.

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true">
<targets>
<target
name="NullTarget"
xsi:type="Null"
/>
</targets>
<rules>
<logger name="*" minlevel="Info" writeTo="NullTarget" />
</rules>
</nlog>

Listing 1: Disabling all logging by defining a null target.

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<targets>
<target
name="WindowsEventLogInfo"
xsi:type="EventLog"
layout="REDBEX ${longdate} ${message}"
source="RedbexApplicationServer"
machineName="."
eventId="1"/>
<target name="ColoredConsole" xsi:type="ColoredConsole"/>
</targets>
<rules>
<logger name="*" minlevel="Trace" writeTo="WindowsEventLogInfo">

<filters>
<when condition="length('${message}') > 100" action="Ignore" />
<when condition="equals('${logger}','MyApps.SomeClass')" action="Ignore" />
<when condition="(level >= LogLevel.Debug and contains('${message}','PleaseDontLogThis')) or level==LogLevel.Warn" action="Ignore" />
<when condition="not starts-with('${message}','PleaseLogThis')" action="Ignore" />
</filters>
</logger>
</rules>
</nlog>

Listing 2: A custom logging configuration that uses advanced filtering in the rules section.

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<targets>
<target name="logfile" xsi:type="File" fileName="c:\temp\logfile.txt" layout="${longdate} ${level:uppercase=true} ${message} ${onexception:${newline}EXCEPTION OCCURRED${newline}${exception:format=tostring}}"/>
</targets>
<rules>
<logger name="*" minlevel="Info" writeTo="logfile" />
</rules>
</nlog>

Listing 3: A very simple logging configuration, just writing to a single file.


Windows Event Log

Last edited: 10/5/2017 11:51:46 AM

Log data issued before the Application Server initializes the logging engine will be logged directly to the Windows Event Log (on the computer the Application Server is running). Also in the default configuration of the logging engine some log data will always be persisted in the Windows Event Log.

In both cases the log entries written to the Windows log will be written to the Application protocol. The source of the event log entries written is always RedbexApplicationServer.


Application Server Instances

Last edited: 10/5/2017 11:51:02 AM

While the files for the Application Server executable program are only be installed once on one computer you can configure multiple instances of the Application Server to be run at the same time on the same computer. I.e. the Application Server may run multiple times on the same computer using different Application Server Databases.

Each Application Server Instance is run as a separate Windows Service and has its own instance configuration. Each Application Server instance must access its own (separate) Application Server Database.

When you install the Application Server using the Application Server Setup Program this Setup Program will automatically create a first instance - this instance is called the primary instance. Uninstalling the Application Server will also remove the primary instance.

If needed you can use the Application Server Instance Setup to install one or more additional instances. Additional instances are not removed when the Application Server is uninstalled but need to be manually.

An Application Server Instance is uniquely identified by the instance identifier, a string you specify on installation of the Application Server or Application Server instance.

Every instance of the Application Server must be licensed separately.

Warning: Each instance of the application server must be configured to use its own Application Server database. Configuring two instances to connect to the same Database will corrupt the data in the database.


Instance identifier

Last edited: 10/5/2017 11:51:26 AM

The instance identifier is a string that uniquely identifies a single instance of the Application Server on a computer. The instance identifier is usually defined when running the Setup Program for the Application Server or the Application Server Instance. It is stored in the instance configuration file and can therefore be changed.

The instance identifier must match the regular expression ^[a-zA-Z][a-zA-Z0-9_]{3,49}$. The Application Server will use the instance Identifier in several places, e.g. as virtual directory for the hosted Web Services.

Note that your license code will only be valid for a specific instance identifier (the identifier set when the license code was requested). When changing the instance identifier you will therefore need a new license code.


Instance configuration file

Last edited: 10/5/2017 11:51:26 AM

Each instance of the Application Server has its own configuration file that specifies some basic settings. Instance configuration files are plain XML files.

Instance configuration files that are created by the Application Server Setup Program are stored in the Application Directory. The Application Server Instance Setup Program stores instance configuration files in the Application Directory of the Application Server Instance. All setup programs will name the instance configuration file as <instanceIdentifier>.icfg.

Which instance configuration file is actually used is decided by the Application Server during startup. If advised by the command line argument -i the Application Server will try to load that instance configuration file. If not advised by the command line the Application Server will load the alphabetically first file in the Application Directory that has the extension .icfg.

Use extreme caution when modifying instance configuration files. Erroneous configuration files will hinder the Application Server to start, or you might even cause data loss. Before modifying configuration files always make a backup of the original file!

The InstanceIdentifier element specifies the instance identifier that will be used by this instance of the Application Server. Each instance must have its own unique (for that computer) instance identifier.

The AssignAuthorPrivilegesToNewFeatures element defines if users creating new features will automatically be assigned Author privilege on that features. Default value for this setting is true.

The CommunicationConfiguration section defines how the Application Server provides its services and therefore also defines how clients can access the Application Server. Table 1 describes all settings in the CommunicationConfiguration section.

The DirectoryEnvironmentConfiguration defines where on the file system the Application Server stores files. These directories are created by the setup programs and the appropriate permissions for these directories are also set by the setup program. If you want to change the location of these directories you will have to create those directories manually and assign the appropriate permissions.

The DatabaseConfiguration section defines how the Application Server can access the Application Server Database. Listing 1 shows an example with integrated security enabled i.e. with Windows authentication. Listing 2 shows an example with username password authentication. Note that if you use username password authentication the password will be stored in this configuration file as plain text. Therefore you should make sure that this configuration file can only be read by the user who runs the Application Server.

Setting | Required | Description
enableTcp | No | Defines if the TCP protocol is enabled for service requests to the Application Server. See chapter Protocols for more information. Default: false
tcpPort | No | Defines the port for TCP communication. See chapter Protocols for more information. Default: 5660 When using TCP as protocol different instances have to use different ports. This restriction does not apply to HTTP connections.
enableHttp | No | Defines if the HTTP protocol is enabled for service requests to the Application Server. See chapter Protocols for more information. Default: true
httpPort | No | Defines the port for HTTP communication. See chapter Protocols for more information. Default: 80
enableHttps | No | Defines if the HTTPS protocol is enabled for service requests to the Application Server. See chapter Protocols for more information. Default: false
httpsPort | No | Defines the port for HTTPS communication. See chapter Protocols for more information. Default: 443
certificateName | No | The name of the certificate in the certificate cache that is used for communication with clients. See chapter Certificates for more information. Default: RedbexDefaultCertificate

Table 1: Settings in the CommunicationConfiguration section

Setting

Required

Description

BinaryStorageDirectory

Yes

Directory for storing binary data. See Directory Environment for more details.

TemporaryDirectory

Yes

Directory for storing temporary data. See Directory Environment for more details.

CacheDirectory

Yes

Directory for storing cache data. See Directory Environment for more details.

LogDirectory

Yes

Directory for storing log files. See Directory Environment for more details.

ModulesDirectory

Yes

Directory for storing modules that are dynamically loaded by the Application Server on start up.

OptionalLogsDirectory

Yes

Directory where the server stores data change log files.

TranslationsDirectory

No

If set to an existing directory this advices the Application Server to read translations from all files in this directory.

This setting is optional and is intended to be used when translating the Application Server into a different language in collaboration with Redbex

Table 2: Settings in the DirectoryEnvironmentConfiguration section

Setting | Required | Description
Server | Yes | Address of the database server, including the database server instance if used. Syntax: <databaseServerAddress>[\<instancename>] Examples: localhost localhost\SQLExpress 192.168.0.12 mydatabaseserver.company.com
Database | Yes | Name of the database to connect to
ConnectionTimeout | No | The connection timeout Default: 15s
IntegratedSecurity | Yes | Defines if integrated security shall be used. If true the Database will be accessed as the user who is running the Application Server. If false you have to specify a username and password.
UserName | Yes if IntegratedSecurity is true | User name to be used if IntegratedSecurity is false.
Password | Yes if IntegratedSecurity is true | Password to be used if IntegratedSecurity is false.

Table 3: Settings in the DatabaseConfiguration section

<?xml version="1.0" encoding="utf-8"?>

<InstanceConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<InstanceIdentifier>services</InstanceIdentifier>

<CommunicationConfiguration>

<EnableTcp>false</EnableTcp>

<EnableHttp>true</EnableHttp>

<EnableHttps>false</EnableHttps>

<TcpPort>5660</TcpPort>

<HttpPort>80</HttpPort>

<HttpsPort>443</HttpsPort>

<CertificateName>RedbexDefaultCertificate</CertificateName>

</CommunicationConfiguration>

<DirectoryEnvironmentConfiguration>

<BinaryStorageDirectory>C:\ProgramData\redbex\A282\Binary</BinaryStorageDirectory>

<TemporaryDirectory>C:\ProgramData\redbex\A282\Temporary</TemporaryDirectory>

<LogDirectory>C:\ProgramData\redbex\A282\Log</LogDirectory>

<CacheDirectory>C:\ProgramData\redbex\A282\Cache</CacheDirectory>

<ModulesDirectory>C:\ProgramData\redbex\A282\modules</ModulesDirectory>

<DataChangeLogsDirectory>C:\ProgramData\redbex\A282\DataChangeLogs</DataChangeLogsDirectory>

</DirectoryEnvironmentConfiguration>

<DatabaseConfiguration>

<IntegratedSecurity>true</IntegratedSecurity>

<Server>dbServer012</Server>

<Database>redbex Application Server Database - A282</Database>

<ConnectionTimeout>15</ConnectionTimeout>

</DatabaseConfiguration>

</InstanceConfiguration>

Listing 1: Example instance configuration file

<?xml version="1.0" encoding="utf-8"?>

<InstanceConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<InstanceIdentifier>services</InstanceIdentifier>

<CommunicationConfiguration>

<EnableTcp>false</EnableTcp>

<EnableHttp>true</EnableHttp>

<EnableHttps>false</EnableHttps>

<TcpPort>5660</TcpPort>

<HttpPort>80</HttpPort>

<HttpsPort>443</HttpsPort>

<CertificateName>RedbexDefaultCertificate</CertificateName>

</CommunicationConfiguration>

<DirectoryEnvironmentConfiguration>

<BinaryStorageDirectory>C:\ProgramData\redbex\A282\Binary</BinaryStorageDirectory>

<TemporaryDirectory>C:\ProgramData\redbex\A282\Temporary</TemporaryDirectory>

<LogDirectory>C:\ProgramData\redbex\A282\Log</LogDirectory>

<CacheDirectory>C:\ProgramData\redbex\A282\Cache</CacheDirectory>

<ModulesDirectory>C:\ProgramData\redbex\A282\modules</ModulesDirectory>

<DataChangeLogsDirectory>C:\ProgramData\redbex\A282\DataChangeLogs</DataChangeLogsDirectory>

</DirectoryEnvironmentConfiguration>

<DatabaseConfiguration>

<IntegratedSecurity>false</IntegratedSecurity>

<Server>dbServer012</Server>

<UserName>RedbexApplicationServer</UserName>

<Password>a(e!§ju34,mn</Password>

<Database>redbex Application Server Database - A282</Database>

<ConnectionTimeout>15</ConnectionTimeout>

</DatabaseConfiguration>

</InstanceConfiguration>

Listing 2: Example instance configuration


Specifying the instance configuration file

Last edited: 10/5/2017 11:51:42 AM

Which instance configuration file is used by an instance of the Application Server can be specified by using a command line argument. The Windows service installed with the Application Server Setup Program or the Application Server Instance Setup program will automatically be configured to point to the right configuration file.

Following information is only needed if you change the location of your instance configuration file.

If this command line argument is not given the Application Server tries to locate the instance configuration file automatically.

If the instance configuration file is erroneous (e.g. due to manual editing) the Application Server will not start. The instance configuration file is loaded at the very beginning of the Application Server startup even before logging is initialized. Therefore the Application Server will log errors with instance configuration files to the Windows event log.

Changes to instance configuration files will only take effect after a restart of the Application Server instance. The instance configuration files must be readable by the user who executes the Application Server. Instance configuration files might include sensitive data, therefore you should carefully plan who can read those files.

Command line

The command line argument for specifying the used instance configuration file is --InstanceConfiguration or -i. You can specify the instance configuration either as relative or as absolute path. Relative paths are interpreted relative to the Application directory. If the specified instance configuration file is not found the Application Server will fail to start.

Note: The user who will actually execute the Application Server (as windows service) must have access to the specified instance configuration file.

Examples:

In the following example the instance configuration file is specified as absolute path

ApplicationServer.exe --InstanceConfiguration="d:\redbex\instanceconfigurations\A254.icfg"

In the following example the instance configuration file is specified as relative path. If the Application Server is installed in c:\program files\redbex\Application Server\ this relative path would be expanded to c:\program files\redbex\Application Server\A252.icfg.

ApplicationServer.exe -i="A252.icfg"

Automatic detection

If the instance configuration file is not specified on the command line the Application Server tries to locate the configuration file automatically. For this the Application Server will search for all files with extension .icfg in the Application directory and will then take the alphabetically first of these files. If the instance configuration file is not specified on the command line and no .icfg files are found in the Application directory the Application server will not start.


Email

Last edited: 10/5/2017 11:51:14 AM

The Application Server can send emails via a configured SMTP Server. Email sending is used for message forwarding and for directly sending important information to users (like login information). It is crucial that email sending works since the only way to deliver login data to new users is via email.


SMTP configuration

Last edited: 10/5/2017 11:51:42 AM

To be able to send emails the Application Server needs to contact an SMTP (Simple Mail Transfer Protocol) server. This can be the SMTP server of your company or of your email provider (like Gmail, GMX etc).

To enable the Application Server to contact an SMTP server you have to specify some parameters in the Global settings. Table 1 gives a summary of SMTP related settings in the Global Settings.

The SMTP: Server and SMTP: Port setting define where the SMTP server is located and on which TCP port it is listening for requests. Note that if the Application Server is behind a firewall and the SMTP server is outside of the firewall you may have to configure your firewall to allow connections.

Setting name | Description
SMTP: Server | Server to use for sending out email. This can be the IP-Address or DNS name of the server. E.g. smtp.mycompany.com or smtp.gmail.com
SMTP: Port | Port on which the smtp server listens. Non-SSL Servers often use port 25 SSL servers often 465 Default: 25
SMTP: User name | Defines if communication with the SMTP server should be done over SSL Default: false
Timeout | Timeout when communicating with the SMTP Server, if the SMTP Server does not answer within that time the server is considered as down. Default: 30
SMTP: Sender address | If SMTP: Use sender's email address is not set this email address is used as the From: address in all outgoing emails. If <%GS_SMTPREQUIREAUTHENTICATION%> is set this is used as the login for the SMTP server. Default: <empty>
SMTP: Sender name | If SMTP: Use sender's email address is not set this is used as the sender name in the From: field of all outgoing emails.
User name | The username for authenticating against the SMTP server Default: <empty>
SMTP: Password | Password used to login to the SMTP server Default: <empty>
SMTP: Use sender's email address | If set the email address of the user sending the message will be used in the From field of the sent emails. If not the SMTP: Sender address will be used an the user's email address will only be used as Reply-To address.
SMTP: Allow attachments | If not set the Application Server will not send Attachments via this SMTP Server. Unset this if your SMTP server does not allow to send attachments, the Application Server will then be adviced to remove attachments from outgoing emails so that they can still be delivered

Table 1: Settings for SMTP configuration in the Global Settings

Using Googles SMTP service

Table 2 lists the settings needed to use Googles SMTP Service. Google implements a series of measures to secure the access to your Gmail account therefore you have to check the following points that might hinder you from using Googles SMTP service immediately.

Enable IMAP: In the email settings of your google mail account enable the IMAP protocol.

Password quality: Make sure your password is at least 7 characters and is strong (according to Google). If you have a weak password Google will not allow you to logon to the SMTP server.

Register sender: Google implements a security feature that might hinder you from connecting to the SMTP Server as long as you did not authenticate the computer from which you are sending. To register your computer, open a web browser on that computer and login to the Gmail web page. If the computer is not yet authenticated you will be guided through the necessary steps.

Setting | Value
SMTP: Server | smtp.gmail.com
SMTP: Port | 587
SMTP: User name | Yes
SMTP: Sender name | The name of your google account (usually your gmail address.
SMTP: Password | The password of your google account

Table 2: Global settings for using Google's SMTP Service


Sending a test email

Last edited: 10/5/2017 11:51:40 AM

In order to verify a user's email address and to verify the SMTP setup you defined in Global Settings the Application Server provides the possibility to send a test email to a user.

Test emails can only be sent if the system permission Manage users and user groups (0) is given.


Email format

Last edited: 10/5/2017 11:51:14 AM

All emails sent by the Application Server are UTF-8 encoded (subject and body). Table 1 describes emails sent by the Application Server. The body of the emails sent by the Application Server is HTML encoded.

Email part

Content

From:

The value used of this email header field depends on your SMTP Setup (see Global Settings).

If you chose SMTP: Use sender's email address in global settings the sending users email address and name will be used for in the email's From: field. E.g. "John Walter Doe" <John.Doe@some-domain.com>

If you did not choose SMTP: Use sender's email address in global settings the default sender email address and name as defined in global settings SMTP: Sender address and SMTP: Sender name will be used.

Sender:

The system email address of the user who sent the message will be used, First, middle and last name will be additionally added. E.g. "John Doe" <John.Doe@some-domain.com>

Reply To:

The system email address of the user who sent the message will be used, First, middle and last name will be additionally added. E.g. "John Doe" <John.Doe@some-domain.com>

X-Mailer:

This is automatically set to

Redbex Application Server - <instance name>

You can use this email field to filter all Messages originating from a specific server.

Subject:

The message subject will be used as email subject

To:

Will only contain the address of the user to whom this message is forwarded or the address that was used as external recipient of the message. Will not show any other recipients.

CC:

Will always be empty

BCC:

Will always be empty

Content type:

HTML

Date:

The send date of the message in the time zone of the used SMTP server

Priority:

Low, Medium or High. Used for defining message priority.

Table 1: Description of emails sent by the Application Server


Licensing

Last edited: 10/5/2017 11:51:28 AM

The software end user license agreement (EULA) between you (the licensee) and Pöyry Infra GmbH (the licensor) gives you the right to use the Application Server software, the Smart Client and the Application Server Database to a certain extent. To enforce the terms of this software license agreement the Application Server requires a license code to be installed before it can be used.

The Application Server is shipped with an installed license code for a limited demo license. If you purchased a Redbex license a license code for that license must be requested to enable all functionality included with that license. The procedure of requesting and installing a license code is called the licensing procedure.

To be able to install a license on the Application Server the Application Server must be able to connect to the Redbex Distribution Server at distribution.redbex.com using HTTP on port 80.

The only part of Redbex that is protected by the license code is the Application Server. Neither the Smart Client, nor the Application Server Database or any other part of the systems need to undergo a licensing procedure before they can be used.


License code

Last edited: 10/5/2017 11:51:26 AM

The license code is the data that is issued to you in order to be able to use the Application Server as granted in the License Agreement. In other words the license code is the machine readable form of your license that is used by the Application Server to enforce the license agreement.

If no valid license code is found for an instance of the Application Server the users wont be able to execute views and therefore won't be able to access features and observations stored with the Application Server.

The installed license code will also enforce license restrictions i.e. it will define to what extent the Application Server can be used, e.g. which feature types can be used, how many features of a specific type you can create, how many users can connect to the Application Server at the same time etc.

Table 1 shows the information stored within the license code. The license code itself is issued in encrypted form.

License code datum | Description
License GUID | Global unique identifier of the license
Licensee name | Name of the person or company who is the licensee of the software
Licensee contact details | Contact details of the licensee
Licensee email | Email address of the person or company who is the licensee of the software
Checksum of licensed operating environment | A checksum of the licensed computer. The checksum is calculated over hardware and software of the computer on which the Application Server is installed.
Restrictions | The license restrictions

Table 1: Administrative data stored within a license code


License code validity

Last edited: 11/8/2017 9:32:22 AM

Table 1 lists the validation rules that are used to check the validity of the installed license code.

The validity of the installed license code is checked on startup of the Application Server and before each creation of a new user session. If the license is found to be not valid the execution of views will be disabled and you wont be able to access features and observations.

Validation rule

Description

Application Server Version

The Application Server requires a license code that matches the current version of the Application Server.

The license code is valid on the current Application Server if the Major Version of the Application Server is less or equal the major version encoded in the license code.

Therefore it is possible that after installation of a new Version of the Application Server you might need a new license code.

Validity period

The license code might define a validity period (a from and a to date) that specifies in which time range the license code is considered as valid.

Validity duration

The license code might define a validity duration (in days), that specifies how long the Application Server can be used with this license code.

The validity duration is mostly used by the demo license. The validity duration is counted from the date of license installation.

Operating environment checksum

A checksum of an operating environment on which this license will be valid. This checksum is automatically provided by the Application Server when requesting a license.

The checksum used is simply the result of a mathematical operation on some of your environments properties, one cannot infer any particular property of your environment from that checksum.

In case you change the operating system or the computer hardware your operating environment checksum might change and you will need to request a new license code.

The demo license is an exception to this rule, this license is not bound to a computer/hardware and may be used on any computer.

Instance identifier

The license code is only valid if the instance identifier encoded in the license code matches the instance identifier of the Application Server instance.

Table 1: Validation rules for license codes


License restrictions

Last edited: 2/1/2018 6:32:04 AM

A license can (and usually will) define certain restrictions on the usage of the Application Server. These restrictions are enforced by the installed license code and the Application Server will restrict its functionality accordingly. Table 2 lists the restrictions that can be set by a license.

License restriction | Description
Allowed feature types Allowed feature count for each allowed feature type Allowed observation count for each allowed feature type | These three restrictions define what feature types can be used, how many features of each of the allowed feature types can be created and how many observations can be created for features of the allowed types. See below for more information.
Maximum number of domains | The license can restrict the number of domains you are allowed to create. Note that the root domain which is always existing is part of the domain count.
Maximum number of concurrent user sessions | Maximum number of concurrent user sessions that can be established at the same point in time. See chapter on session expiration for details on how concurrent sessions are counted.
Maximum number of job threads | The license can restrict the maximum number of concurrently running jobs.
Maximum number of users | The license can restrict the maximum number of users you are allowed to create.
Available export types | Only those export types will be available that are explicitly granted in your license code.
Available import types | Only those import types will be available that are explicitly granted in your license code.

Table 1: License related restrictions on the usage of the Application Server

The license may restrict the feature types you can use i.e. it may restrict the feature types you can use when creating new features. Additionally the license may restrict the number of features you can create for each feature type and the number of observations you can create within features of a specific type i.e. the sum of all observations of features of a given type.

If the license does not restrict the feature types you can use it may still restrict the total number of features and the total number of observations you can create.

If the license restricts the number of features and observations you can create this restriction is not checked on every creation of a new feature or observations but in regular intervals. I.e. it might be possible to create more than the number of allowed features or observations, but if the number of allowed features or observations is exceeded the creation of new feature or observations will be blocked at some point in time.


Product key

Last edited: 11/20/2017 12:08:40 PM

When you purchase Redbex you will get a unique product key that can be used to request a license code from the Distribution Server. The product key is a three part number in the form of 1234567-12345-12345 (regular expression pattern ^\d{7}-\d{5}-\d{5}$. Since the product is used to request license codes and transfer license codes it is confidential and should not be disclosed to other parties.


Requesting a license code

Last edited: 10/5/2017 11:51:26 AM

Once you purchased Redbex and accepted the end user license agreement you will receive a unique product key that can be used to request a license code for the Application Server.

Requesting a license code is done via the internet by sending a license code request to the Distribution Server. The license code request is a piece of encrypted data partly based on information you provide during the licensing process and partly based on data that is generated by the Application Server. The user provided data in the license code request is used to keep record of customers. You should specify a valid email address during the licensing process since important information will be sent to that email address. For a summary of data included in a license code request see table 1.

When the Distribution Server receives a request for a license code it checks if the product key in the license code request is a valid and product key and will then generate a license cod according to the purchasing record and the data provided with the license code request. The generated license code will only be valid on the machine and the Application Server Instance on which the license request code was generated.

When reinstalling the Application Server on another machine, when changing the hardware or operating system, or when changing the instance identifier the license code will become invalid. In that case you will have to re-request a license code. Requesting a license code with a license request code that includes a serial number for which there was already a license issued might not be possible. Pöyry Infra GmbH enforces some restrictions on that to hinder license fraud. Therefore if you face problems when re-requesting a license code please contact support.

After a successful request for a license code, all other licenses that were issued for the same product key will automatically be revoked.

Request datum | Description
Licensee name | User supplied name of the licensee
Licensee contact details | User supplied contact details (address, phone numbers etc.) of the licensee, used to keep our support database up to date.
Licensee email address | User supplied email address. Note that all information issued by Pöyry Infra GmbH concerning licensing of Redbex will be sent to this email address. Therefore we strongly suggest to provide a valid email address
Product key | User supplied product key. The product key you received with the purchase of the software.
Application Server Version | The version of the Application Server for which the license code is requested.
Operating environment checksum | The operating environment checksum for which the license is requested. This checksum is calculated by the Application Server.
Instance identifier | The instance identifier of the Application Server Instance.
Generation date | Date and time when the license code request was issued.

Table 1: Data sent to the licensor as part of the license code request.


Demo license

Last edited: 10/5/2017 11:51:14 AM

The demo license is a free license granted by Pöyry Infra GmbH that allows you to install and use the Redbex system for demonstration purposes.

The Application Server is shipped with a pre-installed license code for the demo license. The demo license is not strictly bound to a specific computer/operating system environment and is not restricted to a specific instance identifier. The demo license defines the restrictions listed in Table 1.

If in your specific scenario the restrictions of the demo license do not allow you to test the product thoroughly please contact Pöyry Infra GmbH and request a customized demo license.

Restriction | Setting in demo license
Validity time span | not restricted
Validity duration | 60 days
Allowed feature type & count | All feature types are allowed, maximum of 15 features per type.
Allowed feature types' observation count | 50 observations for each feature.
Allowed domain count | 5
Maximum concurrent sessions | 3
Maximum number of job threads | 2
Maximum number of users | 4

Table 1: Restrictions defined by the demo license


Transferring a license

Last edited: 10/5/2017 11:51:44 AM

Since the license code is only valid in a specific operating environment and for a specific instance identifier, it is not possible to simply install Application Server on another computer and run it with the same license (e.g. by restoring a backup on another computer).

If you plan to move your installation of the Application Server to a different computer you will have to request a new license code. For this you will again need the product key you received with your purchase. Please read requesting a license code for restrictions that apply to re-requesting a license code.


Automatic license code check

Last edited: 10/5/2017 11:51:26 AM

From time to time the Application Server will automatically check if the currently installed license code is still valid or if a new license code is available. This is done to prevent license fraud and to automatically extend the validity time span of your license.

The automatic license code check will contact the Distribution Server and sends the product key the operating environment checksum calculated on the current operating environment. As a result of this license check a installed license code might be revoked.

Note: If the Application Server cannot connect to the Distribution Server your license might become invalid.


Upgrading a license

Last edited: 10/5/2017 11:51:44 AM

If you purchase a license upgrade for Redbex (e.g. with less restrictions) the new license code can be requested using the same product key that was issued with your original purchase.


Certificates

Last edited: 10/5/2017 11:51:08 AM

The Application Server uses certificates (electronic documents that use digital signatures to bind a public key with an identity) for secure and trustworthy communication between the Application Server and the clients connecting to it.

The Windows operating system provides all the tools for creating, installing and managing certificates. While dealing with certificates is surely an advanced task for Windows system administrators, Redbex makes it easy for you and creates a default certificate on installation of the Application Server - this allows you to have basic security even if you do not want to go into the details of certificate management.

However if you are concerned about security and if you know how to deal with certificates you can use the Application Server with a certificate that is signed by a trustworthy authority.


Default certificate management

Last edited: 10/5/2017 11:51:12 AM

The Application Server can be run with a self signed certificate. While not being as secure as a certificate signed from a trustworthy authority the self signed certificate can be easily installed and provides basic security.

The self signed default certificate is created during installation of the Application Server - unless you advice the Setup Program not to do so. Installation and removing of the default certificate can also be done with a command line utility called CertMgr.exe that is installed along with the Application Server.

Note that the user running the Application Server must have access to the private key associated with the Default certificate. During installation of the Application Server the necessary permissions are automatically set. When using the CertMgr.exe tool be sure to specify the user who runs the application server using the command line arguments. If installing a certificate by hand make sure you also set the appropriate permissions.


CertMgr.exe

Last edited: 10/5/2017 11:51:28 AM

The CertMgr.exe command line utility is located in the application directory of the Application Server. Its purpose is to give you an easy way of dealing with the the self signed default certificates that are used by default for communication between clients and the Application Server.

To run CertMgr open a console window change to the Application directory and type CertMgr.exe with the appropriate command line arguments.

Table 1 describes the command arguments that can be used with CertMgr.exe, listing 1 shows the basic command line syntax and Listing 2 an exemplary usage of the utility

Argument | Description
-i, --Install | Installs the default certificate - needs administrative rights
-r, --Remove | Removes the default certificate if installed - needs administrative
-c, --Check | Checks if the default certificate is installed
-u, --User | Name of the windows user account that runs the Application Server service, mandatory if you specify -i.
-d, --Domain | Name of the windows domain of the account that runs the Application Server Service, , mandatory if you specify -i.
-h, --help | Displays a help screen.

Table 1: Command line options for the CertMgr.exe utility

CertMgr -c | -i [-u <username> [-d <domainname>]] | -r]

Listing 1: Basic syntax of the CertMgr.exe utility.

C:\Program Files\Redbex\Application Server\>certmgr -c

0 30.04.2013 07:40:11 +02:00 Searching for installed default certificate

1 30.04.2013 07:40:11 +02:00 Search criteria:

2 30.04.2013 07:40:11 +02:00 Certificate name: RedbexDefaultCertificate

3 30.04.2013 07:40:11 +02:00 Store name: My

4 30.04.2013 07:40:11 +02:00 Store location: LocalMachine

Default certificate is not installed

C:\Program Files\Redbex\Application Server\>certmgr -i -u scc3b -d at

0 30.04.2013 07:40:24 +02:00 Installing default certificate:

1 30.04.2013 07:40:24 +02:00 Certificate name: RedbexDefaultCertificate

2 30.04.2013 07:40:24 +02:00 Store name: My

3 30.04.2013 07:40:24 +02:00 Store location: LocalMachine

4 30.04.2013 07:40:24 +02:00 Searching for installed default certificate

5 30.04.2013 07:40:24 +02:00 Search criteria:

6 30.04.2013 07:40:24 +02:00 Certificate name: RedbexDefaultCertificate

7 30.04.2013 07:40:24 +02:00 Store name: My

8 30.04.2013 07:40:24 +02:00 Store location: LocalMachine

9 30.04.2013 07:40:24 +02:00 Certificate successfully installed.

10 30.04.2013 07:40:25 +02:00 Adding key file permissions for user: >scc3b< in domain >at<

Default certificate successfully installed

C:\Program Files\Redbex\Application Server\>certmgr -c

0 30.04.2013 07:40:36 +02:00 Searching for installed default certificate

1 30.04.2013 07:40:36 +02:00 Search criteria:

2 30.04.2013 07:40:36 +02:00 Certificate name: RedbexDefaultCertificate

3 30.04.2013 07:40:36 +02:00 Store name: My

4 30.04.2013 07:40:36 +02:00 Store location: LocalMachine

5 30.04.2013 07:40:36 +02:00 Details on installed certificate

6 30.04.2013 07:40:36 +02:00 Issuer name: CN=RedbexDefaultCertificate

7 30.04.2013 07:40:36 +02:00 Has private key: True

8 30.04.2013 07:40:36 +02:00 Subject name: CN=RedbexDefaultCertificate

Default certificate is installed

C:\Program Files\Redbex\Application Server\>certmgr -r

0 30.04.2013 07:40:40 +02:00 Searching for installed default certificate

1 30.04.2013 07:40:40 +02:00 Search criteria:

2 30.04.2013 07:40:40 +02:00 Certificate name: RedbexDefaultCertificate

3 30.04.2013 07:40:40 +02:00 Store name: My

4 30.04.2013 07:40:40 +02:00 Store location: LocalMachine

5 30.04.2013 07:40:40 +02:00 Details on installed certificate

6 30.04.2013 07:40:40 +02:00 Issuer name: CN=RedbexDefaultCertificate

7 30.04.2013 07:40:40 +02:00 Has private key: True

8 30.04.2013 07:40:40 +02:00 Subject name: CN=RedbexDefaultCertificate

9 30.04.2013 07:40:40 +02:00 Removing default certificate

10 30.04.2013 07:40:40 +02:00 Certificate name: RedbexDefaultCertificate

11 30.04.2013 07:40:40 +02:00 Store name: My

12 30.04.2013 07:40:40 +02:00 Store location: LocalMachine

13 30.04.2013 07:40:40 +02:00 Removing certificate with subject: CN=RedbexDefaultCertificate

Default certificate successfully deinstalled

C:\Program Files\Redbex\Application Server\>certmgr -c

0 30.04.2013 07:40:44 +02:00 Searching for installed default certificate

1 30.04.2013 07:40:44 +02:00 Search criteria:

2 30.04.2013 07:40:44 +02:00 Certificate name: RedbexDefaultCertificate

3 30.04.2013 07:40:44 +02:00 Store name: My

4 30.04.2013 07:40:44 +02:00 Store location: LocalMachine

Default certificate is not installed

Listing 2: Exemplary use of the CertMgr.exe utility


Modular updates

Last edited: 3/8/2018 7:30:14 AM

Some parts of the Redbex Application Server can be updated without actually installing a new version of the Redbex Application Server. The Application Server loads these so called modular updates from the Redbex Distribution Server.

On the first start up of the Application Server (after installing the software) the Application Server will automatically try to perform a modular update, future updates are then manually initiated by the user. Modular updates are loaded from the Distribution Server - it is therefore mandatory that a connection to the Distribution Server can be initiated.

Note: Running the modular updates will automatically log out users from the Application Server who do not have the Create user session when server is closed (13) permission. Additionally the server will be temporarily locked, so that no other user can login.

Note: Depending on the contents in your database a modular update might take from several minutes up to several hours, during a modular update users won't be able to access the Application Server!

Table 1 lists the parts of the Application Server that are installed/updated by the modular update.

Data | Description
Feature types | Will update the list of available feature types. Note that even though the online update installs feature types, it is defined by your license if you can use feature types.
Sensor types | Will update the list of sensor types available for the installed feature types.
Classification types | Will update the classification types used in property structure.
Quantities & Units | Will update the units and quantities available to be used in property structures.
Multi-language texts | Will update texts published by the Application Server in multiple languages.
Allowed feature container relations | Updates the rules that define the feature types that can be member of a specific container feature type.
Report types | Report types for the reporting engine.

Table 1: Parts of the Redbex Application Server that are installed/updated with modular updates

You can initiate a modular data update at any time manually via the Redbex Smart Client. The modular data update will then run in the background as a job. To verify the success of the data please refer to the job success status and the job log.

The user who is running the modular data update must have the system permission Perform Distribution Server update (8)


Versioning

Last edited: 11/8/2017 9:32:22 AM

Over time the Application Server will be deployed in different versions, new features might be added, bugs removed etc. To distinguish between different versions of the Application Server each version has a unique version number. Version numbers consist of four components: major, minor, build, and revision. All components are integers greater than or equal to 0. The format of the version number is as follows:

<major version>.<minor version>.<build number>.<revision>

The components are used by convention as follows:

·Major: Application Servers with different major versions are not interchangeable. A higher version number indicates a major rewrite of a product or great enhancements in functionality, where backward compatibility cannot be assumed. If the major version number changes a new license is necessary. A change in the major version number indicates a change in the Web Services API, therefore the client (e.g. the Smart Client) software has to be updated to be compatible with the new Application Server version.

·Minor: If the major version number on two Application Server versions are the same, but the minor version number is different, this indicates significant enhancements. A change in the minor version number indicates a change in the Web Services API, therefore the client (e.g. the Smart Client) software has to be updated to be compatible with the new Application Server version.

·Build: A difference in build number indicates a new version with no significant new features implemented, but a few small improvements and bug fixes. If the Application Server's build number changes clients (e.g. the Smart Client) do not have to be updated.

·Revision: A difference in revision number indicates a new version with small changes e.g. bug fixes. If the Application Server's revision number changes clients (e.g. the Smart Client) do not have to be updated.

Checking the Application Server Database version

When the Redbex Application Server starts up and connects to the Application Server Database it will read out the version of the Application Server Database and decide if the current Application Server supports that database version. This is done by comparing the major and minor component of the database version number to a compatibility version number that is hard coded within the Application Server. In other words all versions of the Application Server database that have a major and minor version number that equals the major and minor compatibility version number hard coded within the Application Server are compatible with that version of the Application Server.

Example: If the Database Version number is 3.4.5.2 and the hard coded compatibility version number in is 3.4.0.0 the Application Server can use that database. If the compatibility version number would be 3.5.0.0 or 2.1.0.0 the Application Server cannot use that database.

The database compatibility version number is logged on application server startup and is also reported by the server information service.


Directory Environment

Last edited: 10/5/2017 11:51:04 AM

Besides the Application Server Database, the Application Server also uses the local file system for storing and reading data. With the exception of the Binary directory all data stored on the file system is reproducible i.e. needs no backup. Table 1 shows directories used by the Application Server.

Directory

Description

Application directory

If not changed during installation the application server directory is <ProgramFiles>\Redbex\Application Server\

All executable files some configuration files and other accompanying files are installed here. <ProgramFiles> is a Windows special folder that is usually points to something like C:\Program Files. The Windows environment variable %ProgramFiles% can be evaluated to show the location of this special folder. Type echo %ProgramFiles% in a console window.

Binary directory

Used for storing binary data. This directory must be backed up together with the Application Server Database for a full backup. Depending on your usage of Redbex this directory might contain a large volume of files and may grow to huge size.

Contents of this directory need to be included in your Backup!

Cache directory

Directory where the Application Server will cache data for faster data retrieval. This data needs no backup since it is just a temporary copy of data stored in the Application Server Database.

Log directory

Directory where log files are stored if you use the default logging configuration. On start up the Application Server will delete all files in this folder older than 10 days.

Modules directory

Directory where modules that extend the Application Servers functionality are stored. The Application Server will create sub directories in this directory as needed.

Optional logs

Directory where optional logs are stored. The user can decide if optional logs will be written or not from within Redbex. Optional logs like the data change log can grow to huge sizes.

Temporary

Folder where the Application Server will store temporary data. This folder needs no backup. Old files are automatically deleted from this folder on every start up of the Application Server.

Table 1: Directories used by the Redbex Application Server

The location of the binary, cache, log and temporary directories is configured in the instance configuration file. If you manually change the directories make sure that different instances of the Application Server will use different directories!

Files in the binary, cache, log and temporary directories are solely managed by the Application Server. Manually adding, modifying, deleting, modifying or renaming files or sub-folders within these folders will result in fatal errors and possible data loss.

Files in the binary, cache, log and temporary directories might contain confident information, therefore we recommend that only the user running the Application Server Windows Service shall have read/write access rights to these folders.

All directories are created during Setup of the Application Server. On startup of the Application Server checks the existence of the binary, cache, log and temporary directories. If they do not exist the Application Server will try to create these directories and if it fails (due to missing operating system permissions) to do so will not start. During startup the Application Server also checks if it can modify files in this directory, if not the Application Server will fail to start.

If you change the Application Server Directories we recommend that you always create these directories yourself and assign the appropriate windows permissions before starting the Application Server.


Command line

Last edited: 10/5/2017 11:51:10 AM

The Application Server executable (ApplicationServer.exe in the Application Directory) accepts several command line arguments. Usually you will never need to use these command line arguments since the Setup Program takes care about them when creating the Windows Services, however for advanced installation scenarios and in some special situations those command line arguments may be very useful.

Command line argument | Description
--InstanceConfiguration or -i | Defines the instance configuration file (*.icfg) to be used. This option is automatically set by the Application Server Setup or the Application Server Instance Setup. See chapter Instance configuration for more details. Example: ApplicationServer.exe -i"c:\Program files\Redbex\Application Server - Instance02\Instance02.icfg"
--NoJobQueuing or -n | Defines that the Application Server shall not que jobs. This argument should only be used for debugging purposes.
--Testing or -t | Defines that the Application Server should run a set of extended self tests on start up. This switch should only be used for debugging purposes.
--InternalLogFile or -l | Defines that the Application Server shall use the given file name as place where problems with the log configuration shall be written. This is useful if you want to use a custom nlog.config file. Parsing errors etc. will then be written to the given file. ApplicationServer.exe -l"c:\temp\InternalLog.txt

Table 1: Command line arguments for the Application Server executable.


Binary data

Last edited: 10/5/2017 11:51:06 AM

Most binary data (files) that the Application Server stores, e.g. as data for instances of a property of type binary value or as data for a message attachment are not stored in the Application Server Database. The Application Server rather stores a reference to the file (a relative path) and additional meta data in the Application Server Database and the file itself on the file system.

Consistency between the files stored on the file system and the references in the database is managed by the Application Server. I.e. if a message attachment is deleted the corresponding file on the file system will be deleted too. Due to database transactions or other unforeseeable events there is still a chance that there are files on the file system that do not have a corresponding file link record in the database. The Application Server has a possibility to clean up these unreferenced files.

In case you need to recover your system from a backup there might be inconsistencies between the links stored in the database and the files stored on the file system, since these parts are backed up separately. The application server can detect and solve these inconsistencies,but still there is an extremely small chance of information loss, see backup for more information.

The directory where the referenced files are stored is defined in the instance configuration file (which is written during installation of the Application Server or the Application Server Instance). The directory given in the configuration is the directory as seen from the Application Server. The Application Server Database does not access these files directly. For performance reasons we recommend that the directory is either physically attached to the Hardware the Application Server runs on or connected via a really fast local network connection. The directory must be readable and writable by the Windows user that runs the Application Server.

In order to preserve information security we strongly recommend to grant write and read access to the directory used for storing referenced file sparingly. Only to the user that runs the Application Server should have read and write access. Additional read access may be needed for the user who runs the backup.

Files may be opened by the Application Server for preview generation, meta data or text extraction (see file storage for more details), the Application Server will never run executable files. Still we strongly recommend to use up to date security software (virus scan) to scan all files stored in that directory.

All files stored will be stored with a unique name (a Global Unique identifier) and without extension. The original name of the file is stored in the reference table in the database.


Startup procedure

Last edited: 10/5/2017 11:51:04 AM

The Application Server is (usually) run as a Windows service i.e. it is a executable that performs specific functions and it is designed not to require user intervention. Windows Services are not started by direct user intervention but by the Windows Service Control Manager.

When started the Application Server has to perform a series of tasks before it can be accessed by users (for example through the Smart Client). Table 1 lists the main tasks the Application Server performs during startup. Depending on various factors the startup process can take anywhere from several seconds to some minutes. Note that the Application Server will show up as running in the Windows operating system long before all the tasks listed in table 1 are executed.

Detailed information about the startup process is mostly recorded using Application Servers logging facility, Some information about the startup process (especially when startup fails) is written to the Windows System Events.

Task

Description

Loading instance configuration

Loads the configuration file for the started instance.

If the Application Server encounters problems during this task it will log these problems to the Windows event log. The Application Server will not start if it encounters problems during this step.

Logging initialization

If the Application Server encounters problems during this task it will log these problems to the Windows event log. The Application Server will not start if it encounters problems during initialization of the global log.

After this point all diagnostic messages will be logged according to the configuration of the logging engine.

Inspection of operating environment

The Application Server will inspect its operating environment. This includes the processor architecture (32 or 64 bit).

Testing directory environment

The Application Server relies on some directories where it stores data. In this step the Application Server checks if all those directories are available.

Test database connection

The Application Server tests if it can access the configured database

If this test fails the Application Server will not start.

Test database version

Tests if the Database Version is supported by the Application Sever.

If this test fails the Application Server will not start.

Readout of global settings

The global settings are read from the database.

The Application Server will fail to start if the global settings cannot be read.

Manager user privileges

The Application Server checks the privileges granted to the manager user created with the Database Setup. If this user does not have all the privileges needed these privileges will be auto assigned in this step.

HTTP Proxy configuration

The Application Server gets the HTTP proxy server configuration and sets the default HTTP proxy server that will be used by the Application Server.

Afterwards the Application Server tests if it can connect to the Redbex Distribution Server. The Application Server will still start if it cannot establish a connection to the distribution Server, however some functionality will be limited.

Test directory environment

Tests if the Application Server has access to the configured path for binary, temporary and cache storage and if the Application Server can create and delete files in these directories.

The Application Server will fail to start if one of these tests fails.

Load license

Loads the currently installed license.

The Application Server will start even if the installed license is not valid. However you cannot login to the Application Server without providing a valid license first.

Load caches

If the system finds persisted caches (as files on the file system) it reads the caches into memory and deletes the file.

Depending on the amount of data handled by that installation of the Application Server the cache files might get huge and therefore may take some time to load.

Cleanup after unclean shutdown

If the system detects an unclean system shutdown (e.g. due to a power failure) it performs tasks to bring the system into a clean state. This includes:

·Closing of ghost sessions (user sessions that were not closed on shutdown)

·Deleting of temporary files

Clear Ghost sessions

If the Application Server was not shutdown cleanly, ghost sessions might remain. During startup these sessions will be closed.

Start job queuing

Job queuing is enabled so that jobs can now be queued and executed

Start job scheduler

The job scheduler is started so that jobs scheduled after this point in time will be executed.

Start services

The Application Server's Services are started, so that clients can access the Services.

As soon as this task is finished an information is written to the Windows Event Log.

Table 1: Main tasks performed by the Application Server during startup. Listed in sequence of execution.


Shutdown

Last edited: 10/5/2017 11:51:04 AM

The Application Server is (usually) run as a Windows service i.e. it is a executable that performs specific functions and it is designed not to require user intervention. Windows Services are not stopped by direct user intervention but by the Windows Service Control Manager.

During shutdown the Application Server performs the tasks listed in table 2 (in the listed sequence). Depending on the amount of data handled by the system the process of a clean shutdown can take some seconds, to be able to finish all shutdown tasks cleanly the Application Server will request more shutdown time from the operating system than the time usually granted to Windows services.This might slow down the shutdown process of your operating system too. Details about the shutdown process are written to the log.

Note that in rare cases the system might not provide the Application Server the time it needs to perform all tasks listed in table one. Especially the Writing caches to disk task might need more time than the system provides. However in these rare cases no information will be lost, only the caches will have to be built anew when the system starts again. If you find that on your system the operating system quits the Application Server before the caches are written (see log file) you can tweak the Windows registry to give server processes more time to quit.Please refer to your operating system documentation on more details on this.

Task | Description
Stop services | No client can access the services of the server from this point in time
Stop job scheduler | No jobs will be triggered from the schedule from this point in time
Stop job queuing | No new jobs can be queued already queued jobs will be aborted with a specific status.
Abort running jobs | All currently running background jobs will be aborted
Close user sessions | All currently opened user sessions will be closed
Writing caches to disk | All caches will be persisted.

Table 1: Tasks performed by the Application Server during shutdown. Listed in sequence of execution.


Caching

Last edited: 10/5/2017 11:51:06 AM

The Application Server uses in-memory data caches for improved performance. By keeping data in memory and not being forced to query data from the Application Server Database every time it is requested, the Application Server can process data magnitudes faster than without caching. With time these caches will accumulate more and more data and therefore the performance of the system will be optimized at the cost of system memory.

Since the building of caches takes some time some of these caches will be persisted to disc on shutdown of the Application Server and read from disk into memory again on startup. See table 1 for a list of caches that are persisted to disc. Depending on the sizes of these caches, writing caches to disc and loading caches will take some time. When starting the Application Server it will only accept requests as soon as all persisted caches are loaded back into memory.

The path where caches persisted can be defined during the setup and is stored in the instance configuration file. We highly recommend to keep the caches on a local disc on the Application Server to speed up Application Server startup and shutdown. Since caches hold only information that is available in the Application Server Database or is calculated on data read from the database necessary to backup those persisted caches.

Cache | Notes
Effective permission cache | If a permission is queried from the system (e.g. does User1 have read permission on Feature1) this query might result in complex queries to the database and therefore take some time to complete. This cache stores permissions that were evaluated once and provides fast access to permissions without complex queries to data base for future queries.
View member cache | This cache that stores the effective members of a view. The cache is refreshed by the Application Server based on a schedule.

Table 1: In-memory caches the Application Server persists to disk on shutdown.


System date & time

Last edited: 10/5/2017 11:51:42 AM

The system date and time, i.e. the date&time value returned by the operating system when queried for the current point in time, is used in many places throughout the system.

In order to prevent inconsistencies with date&time values the Application Server checks the conditions listed in table 1 on every startup.

Condition

Description

Database Server time synchronized

The system date on the database server that hosts the Application Server Database must be within 2 minutes of the system date on the server that hosts the Application Server.

If the Application Server and the Database Server are installed on the same machine this is of course never a problem.

Login attempts older than current date time

All stored authentication attempts must be dated before the current system date.

Table 1: Conditions that have to be fulfilled so that the system date & time is considered valid


Global settings

Last edited: 11/8/2017 9:27:20 AM

The Application Server uses global settings for basic configuration of the system. Global settings can be read by any user and can be modified by users with the system permission Modify global settings (4). Global settings are implemented as configuration settings.

Some global settings can greatly influence performance and security of the overall system, the default values are set to reasonable values but you have to adjust them to fit to your environment. Global settings are a UConfiguration, following chapters describe the settings in each group.


%Text%

Navigation: Application Server > Administration > Global settings >

Active directory

Last edited: 11/8/2017 9:24:40 AM

The active directory settings are used for synchronization of Redbex Users with the users of a specific Active Directory user group.

Setting name | Description
AD Domain name | The NetBIOS domain name of the window domain that will be used for user authentication.
Rebex domain user group | The user group in the Active Directory whose members shall be able to use Redbex. This setting is only necessary if you plan to synchronize Active Directory users with Redbex users.
Synchronization user name | The name of the Active Directory user who is used for synchronizing Redbex Users with users from the user group Rebex domain user group with the local Redbex users
Synchronization user password | The password of the Active Directory user used for syncing.
Keep Local | This setting defines if local Redbex users that have no matching user in the Active Directory group will be deactivated or not.

Table 1: Global settings for Active directory synchronization


%Text%

Navigation: Application Server > Administration > Global settings >

Application Server Information

Last edited: 10/5/2017 11:51:22 AM

Setting name | Description
Application Server address | The Application Server itself cannot determine which address is used to connect to it from the outside. Therefore this setting defines the address that is used by clients to connect to the server. Usually this is the full DNS name of the Server, e.g. server1.redbex.com . When the Application Server sends out login information to users this address will be shown.
Operator | The Name of the Organization that operates the Application Server
Operator web page | Webpage of the Organization that operates the Application Server. Use this setting to point users to a web page where they can get more information about your installation and usage of Redbex.
Administrator telephone number | The telephone number where users can reach the organization or administrator operating the Application Server
Administrator email address | The email address where users can reach the organization or administrator operating the Application Server
Support email | E-mail address that is shown to users for support requests. Default is support@redbex.com
Support phone number | Telephone number that is shown to users for support requests.
Non productive system | If set this setting marks the instance of the Application Serer as being a non-productive instance (e.g. a test or demo system). It is up to the client to decide if and how this setting is shown to users.
Important Information | A text line that can be used to show very important information to the users. Use this to inform users about planned server down times etc. It is up to the client if this information is shown and how it is shown.

Table 1: Application Server Information settings


%Text%

Navigation: Application Server > Administration > Global settings >

Calculated features

Last edited: 10/5/2017 11:51:22 AM

Setting name | Description
Processing: GlobalCalculationMultiplierNameGuid |
Processing: Wait time between access tries [s] | If a calculation cannot be performed because a source feature is currently being calculated this defines the number of seconds to wait till the next try. Default: 60
Processing: Number of tries | If a calculation cannot be performed because a source feature is currently being calculated this defines the number of tries before the calculation will fail. Default: 3
Processing: Disk writing threshold | Number of observations the Application Server will hold in memory on processing Default: 4000
Processing: Disable execution of calculated features | Global switch to disable execution of calculated features. Default: false

Table 1: Global settings for calculated features


%Text%

Navigation: Application Server > Administration > Global settings >

Data change logging

Last edited: 10/5/2017 11:51:22 AM

This group of settings is used for configuring if and how changes to data are logged. See chapter %Text% for more details.

Setting name

Description

Record data changes

If set to true the system will log changes to data in data change log database.

Default: false

Max DB size

Maximum size of a change log database file given in MiB. If the change log database file exceeds this value the Application Server will switch to a new database file.

Default: 100
Minimum = 0.5
Maximum 102400 (100GiB)

Max cache size

Defines the maximum number of change log entries that the Application Server will be cached in memory. If this limit is reached, changes to data in the Application Server database will be delayed until the process that persists change log entries frees space on this cache.

Changes to this setting will only apply after the nest start of data change logging (either server restart or stop and start data change logging)

Default: 5000
Minimum: 1000
Maximum: 1000000

Changes per transaction

Number of change log entries that will be written to the change log database in one transaction. The process persisting change log entries will not persist changes from the queue immediately but will wait until either this number of elements have been added to the queue or the maximum time allowed for waiting till a transaction fills is elapsed (see Maximum transaction wait time)

Default: 100
Minimum: 1
Maximum 5000

Maximum transaction wait time

The maximum number of seconds the process will wait after a change has been added to the queue before it will persist this change even if the number of elements on the queue did not reach the number specified with the global setting Changes per transaction

Default: 300 s

Minimum: 30 s

Maximum: 86400 s

Table 1: Global settings for data change logging


%Text%

Navigation: Application Server > Administration > Global settings >

FTP Proxy configuration

Last edited: 10/5/2017 11:51:22 AM

Setting name | Description
FTP: Proxy server address | Host name or IP address of the Proxy Default: <empty>
FTP: Proxy server type | Type of proxy server. One of the following types can be chosen: ·Http: An HTTP server proxy is to be used. ·None: No server proxy is to be used. ·Open: The "OPEN" command is used to connect to an FTP server through this FTP server proxy. ·Site: The "SITE" command is used to connect to an FTP server through this FTP server proxy. ·Socks4: A SOCKS4 server proxy is to be used. ·Socks5: A SOCKS5 server proxy is to be used. ·User The "USER" command is used to connect to an FTP server through this FTP server proxy. ·Default: None
FTP: Proxy server port | Port on which to connect to the proxy server
FTP: Proxy server user name | If needed this defines the user name to use when logging on to the proxy server. Default: <empty>
FTP: Password | Password to use for connections to the Proxy server Default: <empty>

Table 1: FTP proxy server settings


%Text%

Navigation: Application Server > Administration > Global settings >

HTTP Proxy configuration

Last edited: 10/5/2017 11:51:22 AM

Settings in this group define the HTTP proxy that will be used by the Application Server whenever it needs to connect to the internet using HTTP protocol.

Setting name

Description

Use proxy definition

If set the Http proxy settings defined in the Global settings will be used - and will override any Http proxy settings specified in the proxy server configuration file (see HTTP proxy server configuration for more details).

If set but the proxy configuration is invalid the Application server will use the system default proxy or will try to use direct connections.

Default: false

HTTP Proxy server

Host name, DNS name or IP address of the Proxy server.

Default: <empty>

HTTP Proxy port

Port on which the proxy server listens to requests.

HTTP Proxy username

If the proxy server requires authentication this is username is used. If the proxy server does not require authentication leave this setting empty.

Default: <empty>

HTTP Proxy password

If the proxy server requires authentication this is password is used. If the proxy server does not require authentication leave this setting empty.

Default: <empty>

Bypass local

If set, requests to local Internet resources do not use the proxy server. Local requests are identified by the lack of a period (.) in the URI, as in http://webserver/, or access the local server, including http://localhost, http://loopback, or http://127.0.0.1. If not set, all Internet requests are made through the proxy server.

Bypass addresses

A semicolon separated list of regular expressions that describe URIs that do not use the proxy server when accessed.

Table 1: Configuration of the HTTP proxy


%Text%

Navigation: Application Server > Administration > Global settings >

Mapping

Last edited: 10/5/2017 11:51:22 AM

Settings in this group define are used to configure mapping services that are available for creating map views.

Setting name | Description
Bing Maps Key | The API key for Microsoft's Bing Maps. The Bing Maps raster layer in map views will only work if this API key is given. Note: Redbex does not provide a bin maps key. You have to get that key directly from Microsoft - licensing costs may apply.
Google Maps Api Key | The API key for Google Maps. The Google Maps raster layer in map views will only work if this API key is given. Note: Redbex does not provide a bin maps key. You have to get that key directly from Google - licensing costs may apply.
Default map service | This setting defines what shall be used as default map service. The application server uses this service to visualize map data in some places.
Default WMS service | The definition of the default WMS service. See documentation for the WMS layer type for more details
Default coordinate system | Can be used to define the default coordinate system (projected or geographic) that will be used as the preselected coordinate system. Default: null

Table 1: Global settings for configuration of mapping


%Text%

Navigation: Application Server > Administration > Global settings >

Miscellaneous

Last edited: 10/5/2017 11:51:22 AM

Setting name | Description
Miscellaneous: Disable observation monitoring | Globally disables observation monitoring Default: false
Miscellaneous: Maximum concurrent job count | Maximum number of concurrently running jobs Default: 4
Miscellaneous: Wait time before shutdown [s] | When the Application Server receives the signal to shut down it will try to finish currently running jobs. This value is the grace period in seconds that the Application Server will request from the operating system so that running jobs can be finished. The operating system will not grant this grace period under all circumstances. Default: 10 seconds
Miscellaneous: Maximum threads for calculations | Maximum number of threads the Application server uses to write to the Database in batch operations. The value for this setting depends on the hardware on which your Application Server Database is installed. Usually this will be at most the number of physical CPU cores of your database server. Default: 2
Miscellaneous: Purging active | Defines if the system should constantly purge data in the background Default: true
Server news feed URL | Defines the URL for the RSS feed for news related to this installation of the Application Server. Default: empty
Show feed date | Defines if the date is shown in RSS feeds Default: empty
Enable Application Server profiling | If set to true the system will log detailed information on each API call for in-detail performance analysis.
Default region for phone numbers | This is the region that will be assumed for phone numbers that are not given with a region code (e.g. +49).

Table 1: Miscellaneous global settings


%Text%

Navigation: Application Server > Administration > Global settings >

Password quality

Last edited: 10/5/2017 11:51:22 AM

Setting name | Description
Password quality: Must include digits | If enabled, passwords must contain at least one digit [0-9] Default: false
Password quality: Must include lower and upper-case letters | If enabled passwords must contain at least one letter out of the range [a-z] and one letter out of the range [A-Z] Default: false
Password quality: Must not contain name | If enabled, passwords are not allowed to contain the username. This rule is checked case insensitive. Default: true
Password quality: Must include special character | If enabled passwords must contain at least one the following characters ! @ # $ % ^ & * ? _ ~ - £ ( ) . , = + Default: false
Password quality: Must not contain username | If enabled, passwords are not allowed to contain the user's first, middle or last names. This rule is checked case insensitive. Default: true
Password quality: Minimum length | Defines the minimum length (number of characters) a password must have. Although we do not recommend to allow empty passwords, setting this value to 0 will allow empty passwords. We also do not recommend to use values lower than 8 for this setting. Default: 8

Table 1: Settings defining the required password quality


%Text%

Navigation: Application Server > Administration > Global settings >

SMPP

Last edited: 10/5/2017 11:51:22 AM

This group of settings is used to configure the SMPP (Short Message peer-to-peer) communication that can be used to forward messages via SMS.

Setting name | Description
SMPP Server | DNS name / hostname of the SMPP server to connect to for sending SMS
User name | The username used when connecting to the SMPP
Password | Password used when connecting to the SMPP
SSL | The type of SSL to be used when connecting to the SMPP
Service type | The system type parameter is used to categorize the type of ESME that is binding to the SMSC. Examples include ìVMSî (voice mail system) and ìOTAî (over-the-air activation system). Specification of the system_type is optional - some SMSCs may not require ESMEs to provide this detail.
TON | Indicates Type of Number (TON) of the ESME address. If not known set to Unknown.
NPI | Numbering Plan Indicator (NPI) for ESME address. If not known set to Unknown.
Encoding | Encoding of data according the SMPP 3.4 specification.
SMPP sender number | If specified this phone number will be used when sending SMS, otherwise the mobile phone number of the sending user will be used.
Max. message length | The maximum message length for messages forwarded via SMPP. Redbex will truncate messages to this maximum length during SMS translation. Note that the carrier might still split the messages into several SMS.
Max. messages per minute | Defines how many messages can be sent via the SMPP service within a minute.
Max. messages per hour | Defines how many messages can be sent via the SMPP service within an hour.
Max. messages per 24 hours | Defines how many messages can be sent via the SMPP service within 24 hours.
Max. messages per 7 days | Defines how many messages can be sent via the SMPP service within seven days.
Max. messages per 30 days | Defines how many messages can be sent via the SMPP service within 30 days.

Table 1: Global settings for SMPP forwarding


%Text%

Navigation: Application Server > Administration > Global settings >

SMTP

Last edited: 10/5/2017 11:51:22 AM

Setting name | Description
SMTP: Server | Server to use for sending out email. This can be the IP-Address or DNS name of the server. E.g. smtp.mycompany.com or smtp.gmail.com
SMTP: Port | Port on which the smtp server listens. Non-SSL Servers often use port 25 SSL servers often 465 Default: 25
SMTP: User name | Defines if communication with the SMTP server should be done over SSL Default: false
Timeout | Timeout when communicating with the SMTP Server, if the SMTP Server does not answer within that time the server is considered as down. Default: 30
SMTP: Sender address | If SMTP: Use sender's email address is not set this email address is used as the From: address in all outgoing emails. If <%GS_SMTPREQUIREAUTHENTICATION%> is set this is used as the login for the SMTP server. Default: <empty>
SMTP: Sender name | If SMTP: Use sender's email address is not set this is used as the sender name in the From: field of all outgoing emails.
User name | The username for authenticating against the SMTP server Default: <empty>
SMTP: Password | Password used to login to the SMTP server Default: <empty>
SMTP: Use sender's email address | If set the email address of the user sending the message will be used in the From field of the sent emails. If not the SMTP: Sender address will be used an the user's email address will only be used as Reply-To address.
SMTP: Allow attachments | If not set the Application Server will not send Attachments via this SMTP Server. Unset this if your SMTP server does not allow to send attachments, the Application Server will then be adviced to remove attachments from outgoing emails so that they can still be delivered

Table 1: Global settings for SMTP configuration


%Text%

Navigation: Application Server > Administration > Global settings >

Twilio

Last edited: 10/5/2017 11:51:22 AM

This group of settings is used for configuring the Twilio SMS service that can be used to forward messages via SMS.

Setting name | Description
Twilio account SID | The ID of your Twilio account
Twilio authentication token | The authentication token for your Twilio account (the password to use your Twilio account)
Twilio sender number | The Twilio telephone number that will be used as sender. Use your Twilio phone number here.
Max. message length | The maximum number of messages the Application Server will write to a single Twilio messages. The default is 160. If you set this to a value greater than 160 Twilio will split the message into more SMS (with additional costs)
Max. messages per minute | Defines how many Twilio Messages can be sent by the Application Server within a minute.
Max. messages per hour | Defines how many Twilio Messages can be sent by the Application Server within an hour.
Max. messages per 24 hours | Defines how many Twilio Messages can be sent by the Application Server within 24 hours.
Max. messages per 7 days | Defines how many Twilio Messages can be sent by the Application Server within seven days.
Max. messages per 30 days | Defines how many Twilio Messages can be sent by the Application Server within 30 days.

Table 1: Global settings for the Twilio forwarding


%Text%

Navigation: Application Server > Administration > Global settings >

User Session & Security

Last edited: 10/5/2017 11:51:22 AM

Setting name | Description
<%GS_USERSESSIONALLOWNEWSESSIONS%> | If set to false no new user sessions can be created. The server is the closed. Existing sessions will stay untouched. Default: true
User sessions & security: Authentication slowing threshold | Number of consecutive failed authentication attempts after which the server automatically slows down the response to authentication attempts. Default: 100
User sessions & security: Authentication locking threshold | Number of consecutive failed authentication attempts after which a user is locked. See Repeated authentication failure for details Default: 10
User sessions & security: Default User session timeout [s] | The default threshold in seconds after which a user session is considered as idle. This default value is used for newly created user sessions if the client does not negotiate another session timeout with the Application Server. Default: 1800 seconds.
User sessions & security: Maximum allowed user session timeout [s] | Clients can negotiate a user session idling threshold with the Application Server that is anywhere between 300 seconds and this value. Default: 3600 seconds Validation: ≥ 300
User session abandoned threshold | The threshold in in hours after which a user session is considered as abandoned. Default value: 2h Validation: ≥ 0.25 and ≤ 168
User sessions & security: Maximum password age [d] | Time span in days after which users have to change their password. Default: 3650

Table 1: Settings for user sessions and security


Application Server HTTP proxy configuration

Last edited: 10/5/2017 11:51:04 AM

For accessing the Distribution Server and for accessing other online resources the Application Server must be able to connect to the Internet using HTTP. In many IT-environments HTTP connections to the Internet can only be done by using ah HTTP proxy server. The proxy server acts as a go between for the Application Server and the online resource. It works by listening on a specific port number and forwarding those connections to the internet.

Usually you should have specified your proxy settings during the Application Server Setup. If so the Setup has created a configuration file named HttpProxyConfiguration.xml in the Application Directory. Listing 1 shows an example of such a configuration file. You can however also specify the proxy settings in the Global Settings, in that case the Global Settings will override the settings in the configuration file. If there no proxy server configured in the Global Settings and also no configuration file the Application Server will use the default Settings given by the Operating System.

Table 1 shows the order in which the Application Server searches for the HTTP proxy settings. The first found configuration is used.

Source | Notes
Global settings | Used if the Global Setting Use proxy definition is set and the settings HTTP Proxy server, HTTP Proxy port, HTTP Proxy username, HTTP Proxy password define a valid proxy configuration.
HttpProxyConfiguration.xml | Used if file is found and configuration in this file is valid
System settings | If the Application Server can detect the system default settings

Table 1: Sources for HTTP proxy configuration in the sequence they are searched by the Application Server

If you did not configure the HTTP proxy server during setup of the Application Server you may create or modify this file manually (listing 1 shows a template).

Modifying the configuration file

The configuration file contains nodes for all the possible proxy settings. The EncryptedSerialization setting defines if the Password is interpreted as encrypted string or a plain string. The configuration file written by the Setup will use an encrypted password. If you want to modify this file manually you will have to use a plain text password and accordingly you will have to set EncryptedSerialization to false. If you store a plaintext password make sure that only the user running the Application Server has read access to this configuration file.

Listing 1: Example HttpProxyConfiguration.xml

<?xml version="1.0" encoding="utf-8"?>
<HttpProxyConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<EncryptedSerialization>false</EncryptedSerialization>
<ProxyServerHost>yourproxyserver.com</ProxyServerHost>
<Port>8080</Port>
<Username>RedbexService</Username>
<Password>yourpassword</Password>
<BypassLocal>false</BypassLocal>
</HttpProxyConfiguration>

Listing 2: Template for the WebProxyConfiguration.xml


Protocols

Last edited: 10/5/2017 11:51:32 AM

The services provided by the Application Server can be accessed from Clients (like the Smart Client) using TCP, HTTP or HTTPS network protocols. The reason for supporting multiple protocols is that each protocol has its pros and cons concerning information security, ease of configuration and performance. Table 1 gives an overview of the pros and cons of each protocol. Note that not all clients support all protocols.

Protocol | Pro | Con
TCP | Fastest protocol Simple configuration Uses self signed certificate by default. Can be configured to use a certificate signed by a trusted authority. | No information security on data transmission, passwords transmitted in clear text Suitable only for Local area networks, does usually not pass firewalls, NAT etc.
HTTP | Internet enabled, passes firewalls, NAT etc Simple configuration Uses self signed certificate by default. Can be configured to use a certificate signed by a trusted authority. | No information security on data transmission. Slower than TCP
HTTPS | Secure, internet enabled, passes firewalls NAT etc. easily | Need to have a valid certificate for your server. Needs in depth knowledge of certificates to be configured.

Table 1: Pros and cons of different protocols

Which protocols shall be enabled or disabled is totally depending on your local situation. Table 2 lists some common situations and gives a recommendation on which protocol configurations to enable or disable.

Situation | Recommendation
Single computer installation | enable TCP disable HTTP
Installation in local area network, no firewalls or NAT between client and server, network is trusted | enable TCP disable HTTP
Installation on an internet faced server, clients access Application Server through internet. Ease of configuration is primary objective, security requirements are low. | disable TCP enable HTTP d
Installation on an internet faced server, clients access Application Server through internet or local area network Ease of configuration is primary objective, security requirements are low. | enable TCP enable HTTP
Installation on an internet faced server, clients access Application Server through internet. Information security is primary objective. | disable TCP enable HTTP
Installation on an internet faced server, clients access Application Server through internet or through a trusted local area network Information security is primary objective. | enable TCP enable HTTP Make sure that the used TCP port is not tunneled through your firewall.

Table 2: Recommendation of protocols depending on the situation

The Application Server implements a service oriented architecture, therefore all the functionality of the Application Server are exposed as Services. These services are utilized by the Smart Client or other client software that wants to interact with the Application Server.

Depending on your configuration the services provided by the Application Server can be exposed via HTTP or TCP using SOAP as message format.

The Application Server is built on top of Microsoft's Windows Communication Foundation API that is meant for designing and deploying distributed applications under service-oriented architecture (SOA) implementation. Clients can consume multiple services; services can be consumed by multiple clients. (see the related Wikipedia article for a quick introduction to WCF)

A client connects to a service via a service endpoint. Each the service endpoint has an address and binding properties that specify how data will be transferred between client and Application Server when this endpoint is used (this includes the protocol, security mechanisms used etc). One service might be exposed via various end points with different bindings. Which bindings are actually available in your installation depends on the configuration of your system.


Cleaning up file references

Last edited: 10/5/2017 11:51:10 AM

Binary files that are stored by the Application Server are physically stored in a user configurable directory. The Application Server Database keeps links to these files. Due to technical reasons there are some cases in which the files stored on the file system are not deleted when the reference in the database is deleted. Therefore over time a bunch of orphan files might be left on the file system. From time to time it is therefore advisable to clean up these orphans. The Application Server has a specific job type you can use to clean up these orphans.


%Text%

Navigation: Application Server > Administration >

General text templates

Last edited: 10/30/2017 2:21:56 PM

While text templates usually defined along with some objects in the user creates (e.g. in the configuration setting of a Map view) there are some places where the Application Server makes use of General text templates.

Global text templates can be modified by users with the system permission Modify general text templates (26).

Some of these general text templates come predefined with a new installation of Redbex.

Type | Usage
Test email subject | When sending out a test email to a user or a list of users the email subject is created through execution of this text template.
Test email body | When sending out a test email to a user or a list of users the email body is created through execution of this text template.
Access information email subject | When sending out the details for accessing the Application Server the e-mail subject of this e-mail is created through execution of this text template
Access information email body | When sending out the details for accessing the Application Server the e-mail body of this e-mail is created through execution of this text template
Connection data email subject | When sending out connection data e-mails to a user or a list of users the e-mail subject is created through execution of this text template.
Connection data email body | When sending out connection data e-mails to a user or a list of users the e-mail body is created through execution of this text template.
Default observation plan reminder subject | This template defines the subject of a reminder message that will be sent when an observation plan is about to be violated, and if the observation plan does not define its own subject.
Default observation plan reminder body | This template defines the body of a reminder message that will be sent when an observation plan is about to be violated, and if the observation plan does not define its own body.
Default observation monitoring subject | When a message is defined as a resulting action of an observation monitoring definition this text template defines the subject that will be used if no other subject was defined with the observation plan definition.
Default observation monitoring body | When a message is defined as a resulting action of an observation monitoring definition this text template defines the body that will be used if no other body was defined with the observation plan definition.

Table 1: Usages of general text templates


%Text%

Navigation: Application Server > Administration >

Translation Support

Last edited: 10/5/2017 11:51:04 AM

By default the Application Server will read multilingual labels from the Application Server Database during start up of the Application Server and whenever the labels are newly downloaded from the Redbex Distribution Server.

If the instance configuration file specifies a directory for translation files the Application Server will read translations from all files in this directory. The translation files must have a specific format. The Application Server will automatically detect changes to files in the specified directory and will update the its multilingual labels accordingly.


%Text%

Navigation: Application Server > Administration >

Server API profiling

Last edited: 10/5/2017 11:51:40 AM

For detailed analysis of the Application Server Web Services API usage the Application Server can be configured to log all calls to API Services with detailed information. The log information is intended to be used by Redbex for in detail analysis of the performance of an Application Server installation.

By default Server API profiling is not turned on, the global setting Application Server Profiling can be used to turn on the API profiling.

The log files for the profiling information are stored in the Optional logs directory. When turned on API server profiling can generate huge amounts of data, therefore take that you have enough storage space available in the optional logs directory.

Log files are named ServerProfiling_<yyyyMMddhhmmss>.log where yyyyMMddhhmmss is the date of creation of the log file. The Application Server will limit the size of a single log file, if the logged information exceeds this size a new log file will be created.


Performance monitoring

Last edited: 11/8/2017 9:15:54 AM

The Redbex <%APPLICATIONSERVER% performance and status can be monitored using the Windows Performance Monitor. The Windows Performance Monitor is included in all versions of Windows operating systems, it allows you to examine how programs you run affect your computer's performance, both in real time and by collecting log data for later analysis.

During installation of the Redbex Application Server the setup program creates a performance counter category named Redbex Application Server and several performance counters within this category. Table 1 lists the created counters and their meaning.

Using the Window's perfmon.exe utility (the graphical user interface to the Windows Performance Monitor included with all versions of Windows) you can monitor all these performance counters (of course also in connection with other Windows performance counters).

The Windows Performance Monitor supports monitoring multiple instances of counters. The performance counters in the Redbex Application Server category make use of this to enable monitoring of multiple instances of the Redbex Application Server separately.

Counter name | Description
User session count | Number of currently open user sessions. This counter includes active, idle and abandoned sessions.
User sessions/sec | Number of user sessions created per second.
API calls/sec | The number of API calls received by the Application Server per second. This number is a good general indicator of the usage intensity of the Application Server
API call average processing time | Average time in milliseconds it takes for a single API call to be processed. This number expresses the average time in milliseconds it takes for the server to answer a single API call from a client. This counter is a good indicator for the general system performance.
Jobs on queue | Number of jobs on the job queue. Jobs on the queue do not directly influence the overall performance of the Application Server, however this performance counter can be used to monitor if the server is capable of processing all the jobs queued.
Jobs running | Number of jobs that are currently processed. The number of concurrently processed jobs is limited by a global setting.
Content purging queue size | Number of items on the content purging queue. A growing purging queue is usually a sign that big numbers of features or observations are marked for deletion in quick succession - i.e. the purging process cannot handle existing requests before new requests are pushed on the queue.
Content purging average time | Average time (in milliseconds) a content purging request takes till the data was actually deleted in the Redbex Application Server Database.
Features created/sec | Number of features created per second
Features modified/sec | Number of features modified per second
Features marked for deletion/sec | Number of features marked for deletion per second
Observations created/sec | Number of observations created per second
Observations modified/sec | Number of observations modified per second
Observations marked for deletion/sec | Number of observations marked for deletion per sec
Data change log entries not persisted | Number of data change logs entries only stored in memory and waiting to be persisted. This counter can be used to optimize the settings for data change logging.

Table 1: Performance counters for monitoring Application Server performance


Application Server Database

Last edited: 10/25/2017 8:06:44 AM

The Application Server Database is used to store most of the data managed by the Application Server and nearly all of the configuration data needed by the Application Server. As the name implies the Application Server Database is solely accessed by the Application Server and not accessed directly from clients as the Smart Client.

The documentation in this part of the Reference Manual is therefore rather technical and mainly of interest for database system administrators.


Do not touch!

Last edited: 10/5/2017 11:51:14 AM

Well, we guess you already know that but still we want to remind you. The Application Server relies on the structure and the data of the Application Server Database. Any changes to the database schema (including tables, columns, triggers, views, stored procedure etc) will likely lead to fatal errors and possible data loss. The data stored within the tables of the database is managed by the Application Server. Any changes to the data that are not done from the Application Server will bypass the business logic of the Application Server and therefore will likely destroy data integrity which might lead to fatal (unrecoverable) errors and possible data loss!

Do never modify the database structure or the data contained in the database directly! This might lead to irreversible loss of data.


Technical platform

Last edited: 10/5/2017 11:51:44 AM

The Application Server Database is a Database that runs on a Microsoft® SQL Server. Microsoft SQL Server is not part of Redbex but has to be downloaded and licensed separately from Microsoft. However for small installations the free Express versions of SQL Server can be used.

See software requirements in the Application Server Database Installation Guide for a list of supported SQL Server versions.


Versioning

Last edited: 11/8/2017 9:32:46 AM

Over time the Application Server Database will be deployed in different versions. The database structure including tables, relations, stored procedures etc will differ between different versions.

To distinguish between different versions of the Application Server Databases each version has a unique version number. Version numbers consist of two components: major and minor. All components are be integers greater than or equal to 0. The format of the version number is as follows:

<major version>.<minor version>.<build number>.<revision>

The components are used by convention as follows:

·Major: Application Server Databases with different major versions are not interchangeable. A higher version number indicates a major structure change in the databases where backward compatibility cannot be assumed.

·Minor: If the major version number on two Application Server Database versions are the same, but the minor version number is different, this indicates significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of the product or a fully backward-compatible new version of the product.

·Build: A difference in build number indicates a new version with no significant new features implemented, however a few small improvements may be included. A change in the build number does not break compatibility with an already installed Application Server.

·Revision: A difference in revision number indicates a new version with small changes e.g. bug fixes. A change in the build number does not break compatibility with an already installed Application Server.

Whenever the Application Server starts up it will check the Version of the database, see Application Server versioning for details.


Schemas

Last edited: 10/5/2017 11:51:36 AM

The Application Server Database uses a the default DBO scheme for all objects.


Collation

Last edited: 10/5/2017 11:51:10 AM

On installation of an Application Server Database the installer will set the collation of the database to the database server's default collation.

In SQL Server the collation is used for defining the code page that is used to store non-Unicode data and for sorting non-Unicode data types. Since The Application Server uses no non-Unicode data types the collation setting will not influence the Application Server.


Smart Client

Last edited: 11/8/2017 9:32:30 AM

The Redbex Smart Client is a Windows application that provides a user interface to data and services provided by Redbex Application Servers. Being the primarily user interface for the Redbex Application Server developed by Pöyry Infra GmbH the Smart Client covers most of the Application Servers functionality.

Note that due to the open design of the Application Server other client software (perhaps not even published by Pöyry Infra GmbH) might also provide a user interface to the functionality of the Application Server e.g. web clients or clients for mobile devices.

The Smart Client can connect to any Redbex Application Server, as long as the versions are compatible (you may also install different Versions of the Smart Client in parallel). The Application Server the Smart Client connects to can be installed on the same computer, in the same local area network or somewhere on the internet.

In comparison to a Web Browser based user interface the Smart Client is more powerful, provides a richer user interface and can post-process data it retrieved from the Application Server. In comparison to a traditional Rich Client Graphical User Interface it does not implement any business logic. I.e. all the logic for processing data etc. resides on the Application Server.

The Smart Client comes in three different flavors: Smart Client Full, Smart Client Light and Smart Client Portable. These three flavors are only different in terms of installation but provide the same functionality.


%Text%

Navigation: Smart Client >

General Information

Last edited: 10/5/2017 11:51:36 AM

Following chapters give some general information about the Smart Client and introduces basic concepts that are beneficial for an understanding of how the Smart Client works, and how the Smart Client can be efficiently used.

The Smart Client implements a docking window interface that can be easily customized to fit your requirements. The Smart Client can work with multiple MDI (multiple document interface) areas that are also perfectly suited for multi-monitor setups. Figure 1 shows some of the main elements that make up the Smart Client user interface. The window's title bar (figure 1:1) shows the main parameters of the current connection (if connected to an Application Server). The Ribbon (figure 1:2) provides access to many windows and other functionalities. Below the ribbon a Ribbon Dock area can be shown, figure 1:3 shows the Search Ribbon Dock.

The Status Bar (figure 1:6) shows important messages from the system and other information that might be relevant to understand the current behavior of the Smart Client. Tool Windows (e.g. figure 1:4) and Document Windows (e.g. figure 1:5) make up the rest of the user interface. The Smart Client provides mighty possibilities for arranging Tool Windows and Document Windows according to your personal preferences. The layout of your windows is persisted when you close the Smart Client.


%Text%

Navigation: Smart Client > General Information >

User interface basics

Last edited: 10/5/2017 11:51:36 AM

The Smart Client implements a docking window interface that can be easily customized to fit your requirements. The Smart Client can work with multiple MDI (multiple document interface) areas that are also perfectly suited for multi-monitor setups.

Figure 1 shows some of the main elements that make up the Smart Client user interface. The window's title bar (figure 1:1) shows the main parameters of the current connection (if connected to an Application Server). The Ribbon (figure 1:2) provides access to many windows and other functionalities. Below the ribbon a Ribbon Dock area can be shown, figure4 1:3 shows the Search Ribbon Dock. The status bar (figure 1:6) shows important messages from the system and other information that might be relevant to understand the current behavior of the Smart Client.

Tool Windows (e.g. figure 1:4) and Document Windows (e.g. figure 1:5) make up the rest of the user interface. The Smart Client provides mighty possibilities for arranging Tool Windows and Document Windows according to your personal preferences. The layout of your windows is persisted when you close the Smart Client.

Figure 1: The Redbex Smart Client user interface.


%Text%

Navigation: Smart Client > General Information > User interface basics >

Ribbon

Last edited: 10/5/2017 11:51:34 AM

The Ribbon is a command bar that organizes much of the Smart Client's functionality into a series of Ribbon tabs (figure 1:3) at the top of the Smart Client's main window. The ribbon replaces both the traditional menu bar and toolbars.

The Ribbon tabs are composed of groups (figure 1:4), which are a labeled set of closely related commands (figure 1: 5). In addition to tabs and groups, the ribbon consists of:

·A Backstage View that presents a menu of commands that involve doing something to or with the Smart Client application. The Backstage View can be accessed by selecting the first tab in the ribbon (figure 1:2).

·A Quick Access Toolbar, (figure 1:1) which is a small toolbar that displays frequently used commands.

·Enhanced tool-tips, which concisely explain their associated commands (figure 3).

You can use the collapse button (figure 2:1) to minimize the screen area occupied by the ribbon, the tabs will then be dynamically expanded when you click on a tab's header. The Help button (figure 2:2) can be used to open up the Reference Manual.

When activated by selecting the Backstage menu tab, the Backstage View covers the whole screen. On the left side containing of several Backstage Menu items (figure 4). Each of this items can either directly initiate an action or can show more details in the detail area of the Backstage View. See chapter Backstage View for more details.

Figure 1: Left side of the ribbon

Figure 2: right side of the ribbon

Figure 3: Enhanced tool-tips for ribbon buttons

Figure 4: The Backstage Menu of the Smart Client.


%Text%

Navigation: Smart Client > General Information > User interface basics >

Help

Last edited: 10/5/2017 11:51:22 AM

The Smart Client provides context sensitive help. When pressing F1 the Reference Manual will be opened with the chapter that provides information about the window that is currently in focus.

You may also open the Reference Manual (non context sensitive) by selecting the Help button in the top right corner of the Ribbon (figure 1).

Whenever you call context sensitive help the Smart Client will open the help resources that are specified in the Smart Client Settings. By default this is set to use the online documentation provided by Pöyry. See chapter Smart Client Settings for more information.

Figure 1: The help command button in the Ribbon.


%Text%

Navigation: Smart Client > General Information > User interface basics >

Windows

Last edited: 11/8/2017 9:29:40 AM

The Smart Client uses two different types of windows tool windows and document windows.

Tool windows can be docked, floated, auto-hidden, or moved to an optional docking area. They can be dragged to new locations and attached to each other to form tab groups. Complex hierarchies can be created and each control in the hierarchy has the ability to be resized via a splitter. Tool windows can also be displayed as document windows.

Document windows are typically displayed in tabbed document window areas, but can also be floated. They are intended to have a shorter lifespan than tool windows.

Tool windows can only be started once, e.g. you can only start one Domain Explorer. Document windows can be started several times. E.g. you can open several View windows editing different views at the same time.


%Text%

Navigation: Smart Client > General Information > User interface basics > Windows >

Docking states

Last edited: 10/5/2017 11:51:14 AM

There are four states in which windows can be: auto-hide, docked, document, and floating. Document windows can only be in the document and floating states, while tool windows are more flexible and can be in any of the four states.

A tool window is in auto-hide state when its tab appears along one of four outer edges of a dock site. Hovering over the tab makes the tool window's content slide into view. The content remains visible while it has focus or the mouse is over it. When the focus and mouse leave the content area, the tool window slides back out of view, while its tab remains visible.

A tool window is considered docked when it is fully visible but not within the tabbed document area. You can use the docking pin in the tool window's title bar to switch between docked and auto hide status.

A window is in document state when it is within the tabbed document area.

A tool or document window that is in floating state is within a rafting window. A tool window can be in a rafting window by itself or as part of a tool window hierarchy. The rafting window can be moved anywhere above the dock site hierarchy and can be docked during drag operations. The rafting window can be

ToolWindow |
Figure 1: The view explorer tool window in docked state. | Figure 2: The view explorer tool window docked as document window
Figure 3: The view explorer attached to the view explorer tool window


%Text%

Navigation: Smart Client > General Information > User interface basics > Windows >

Switching windows

Last edited: 10/5/2017 11:51:42 AM

To quickly navigate between open windows via the keyboard the Smart Client uses the Switcher that becomes visible when you press Crtl-Tab or one of the other keyboard shortcuts listed in table 1. The switcher allows you to easily select one of the currently open windows and activate this window.

When the Switcher is opened with one of the Ctrl Keyboard shortcuts it is in document window mode, meaning that repeatedly pressing Tab or shift tab while keeping Ctrl pressed will loop through all open document windows. When the Switcher is opened with one of the Alt keyboard shortcuts it is in tool window mode, meaning that repeatedly pressing F7 or Shift + F7 allows you to select one of the open tool windows.

To switch between open windows you can use the Keyboard shortcuts listed in Table 1. When the Switcher is in Document Window mode you can also use the arrow keys to navigate between open document windows. Also when the Switcher is opened you can use the mouse to select a Windows (both tool windows and document windows).

Shortcut | Description
Ctrl + Tab | Select next document window
Ctrl+ Shift + Tab | Select previous document window
Alt + F7 | Select next tool window
Alt + Shift + F7 | Select previous tool window

Table 1: Keyboard shortcuts for navigating between open windows

Figure 1: The switcher for navigating between opened windows.


%Text%

Navigation: Smart Client > General Information > User interface basics > Windows >

Saving windows layout

Last edited: 10/5/2017 11:51:34 AM

The layout of the open windows is saved when you exit the Smart Client. You may reset the window layout to the default (the layout when you first started the Smart Client) by selecting Reset window layout in the Backstage View.

Figure 1: Resetting the window layout


%Text%

Navigation: Smart Client > General Information > User interface basics > Windows >

Modal windows

Last edited: 10/5/2017 11:51:28 AM

Modal windows are windows that block the rest of the Smart Client's user interface as long as they are opened. Once opened modal windows have to be closed to access the Smart Clients User interface again.

While the Smart Client generally avoids the usage of modal windows it is sometimes inevitable.

Figure 1: The Connect To Application Server window is a modal window, blocking the rest of the user interface


%Text%

Navigation: Smart Client > General Information > User interface basics > Windows >

Window modal windows

Last edited: 10/5/2017 11:51:46 AM

Window modal windows are similar to modal windows with the difference that they block only the window from which they were opened (the parent window) and not the whole Smart Client's user interface. Once opened these windows have to be closed before you can access the parent window again.

Window modal windows cannot be resized. Note that if the parent window is very small you might not see the whole window modal window.

Figure 1: Creating a new link in Associated data with a window modal window


%Text%

Navigation: Smart Client > General Information > User interface basics >

Messages

Last edited: 10/5/2017 11:51:28 AM

Messages are modal windows the Smart Client uses to display errors and warnings, ask for confirmation and to display other important notifications that needs immediate user interaction.

Note that the Smart Client uses output messages instead of displaying messages wherever possible. Messages are only displayed for severe errors, warnings, confirmations and really important notifications.

Figure 1: A modal message window


%Text%

Navigation: Smart Client > General Information > User interface basics >

Status bar

Last edited: 11/8/2017 9:31:18 AM

The Status bar, an small area on the bottom of the Smart Client's main window is used to show output messages and to display other important information to the user. The status bar is separated into panels.

If your screen resolution is very low you can configure the Smart Client to not show the status bar. However in most cases it is advisable to show the status bar.

The leftmost panel of the status bar is used to display the latest output message and provides the possibility to start the Output messages window and to open the action log for the currently displayed output message.

Hovering the cursor over the displayed output message will bring up a tool tip showing the last 5 output message (see figure 1). Double clicking the message text will start the output window (or if the output window is already started will bring it to the front). Double clicking on the icon of the displayed output message will show the detailed log for the message (if a log is available).

The right panel in the status bar shows the current domain focus. You can use this panel to set the domain focus. To do hover the panel and a drop down filter list will appear that can be used to set the domain focus (see figure 2).

Figure 1: The Smart Client status bar.

Figure 2: Changing the domain focus form the status bar


%Text%

Navigation: Smart Client > General Information > User interface basics >

Feature search

Last edited: 11/8/2017 9:24:44 AM

The Feature Search is a Ribbon Dock Area that when opened is docked to the bottom of the Ribbon. From this Dock Area you can quickly search for features.

The Dock Area can be opened from the Quick Access Toolbar or with the keyboard shortcut Ctrl+Shift.+F

To perform a Feature Search the system permission List all Features (27) must be granted.

From the Domain drop-down Filter List (figure 2:1) list select zero one or more domains. Only features of these domains will be in the search result. If no domain is selected features of any domain will be included in the search result

From the Feature type drop-down filter list (figure 2:2) select zero one or more feature types. Only features of these types will be included in the search result. If no feature types are selected, features of any type will be included in the search result

In the Feature subtype text box (figure 2:3) enter a simple wildcard pattern if you want the search to be limited to subtypes whose name match that wildcard expression. Leave this text box empty if you do not want limit the search to specific feature subtypes.

In the Feature name text box (figure 2:4) enter a simple wildcard pattern. Note that this text box must not be empty and must at least contain one non wildcard character.

To execute the search click the Search (figure 2:5) or pres Ctrl+Enter.

The results of the search will be sent to the Feature Selection.

Figure 1: Opening Feature Search from the Quick Access Toolbar

Figure 2: The Feature Search Window, docked to the bottom of the Ribbon


%Text%

Navigation: Smart Client > General Information > User interface basics >

General keyboard shortcuts

Last edited: 10/5/2017 11:51:20 AM

Throughout the Smart Client you can use keyboard shortcuts to speed up work. The shortcuts available depend on the currently focused element and window focus. E.g. if the focus is currently on a window that has does not change any data the Ctrl-S keyboard shortcut is not available.

Table 1 lists common keyboard shortcuts that are available in different contexts. Refer to the controls chapter for additional keyboard shortcuts for specific controls.

Shortcut | Description
F1 | Opens help, if available context sensitive
F2 | Renames a selected object
F5 | Reload data form the Application Server or refresh the display of data.
Del | Delete the selected object
Ctrl-N | Create a new object
Ctrl-S | Save changes in current context
Ctrl-Z | Undo changes
Ctrl-C | Copy
Ctrl-X | Cut
Ctrl-V | Paste

Table 1: Common Keyboard shortcuts.


%Text%

Navigation: Smart Client > General Information > User interface basics >

Drag & Drop

Last edited: 10/5/2017 11:51:14 AM

The Smart Client makes intensive use of Drag and Drop, i.e. many different actions can be accomplished by grabbing an object with the mouse and dragging it to a different location or onto another object and dropping it there.

Areas where something can be dropped have (in nearly all cases) a light green background color. If you drag an object over an area where dropping is possible and if the dragged object is an object that can be dropped there the mouse cursor is shown as displayed in figure 1:1. If the dragged objects cannot be dropped on an area or if the type of the dragged object is not expected at the drop area the mouse cursor is shown as displayed in figure 1:2

Figure 1: Example for Drag & Drop


%Text%

Navigation: Smart Client > General Information >

Controls

Last edited: 10/5/2017 11:51:06 AM

For data entry and display of data the Smart Client uses controls that are placed in windows. While most of these controls are default Windows controls that will surely be familiar to you the following chapters gives some detail information that might help you in understanding and efficiently using the Smart Client's user interface.


Check box

Last edited: 10/5/2017 11:51:34 AM

With a check box, you make a decision between two opposite choices or between 2 opposite choices and null. The check box label indicates the selected state, the meaning of the cleared state is the opposite of the selected state.

CheckBox

Figure 1: Example of a check box

With a selected and unselected state check boxes usually represent Boolean data. However in some cases that data might also allow null values (3 valued logic). This null state is displayed as fully filled check box. If the check box allows null values you can set the value to null clicking twice on the check box or by hitting Space twice.

In this documentation we refer to check boxes as check box together with the label text, or simply by the label text.

Key | Meaning
Space | Select or deselect check box
Del | Set check box to null (only if supported)

Table 1: Keyboard shortcuts for check boxes


Combo box

Last edited: 10/5/2017 11:51:34 AM

With a Combo box combo box, users make a choice among a list of mutually exclusive values. Users can choose one and only one option. Choosing a value from a the provided list can be done by typing the name of the value or by selecting the element from the list.

A combo box is similar to a Drop-down list with the difference that the drop down list does not support typing. For keyboard shortcuts see the documentation of the drop-down list.

Combo boxes that support null will show a Command button on top of the list (see figure 2) that can be use to set the value to null. Alternatively you can use the backspace key.

Figure 1: Typing in a combo box with autocomplete

Figure 2: A combo box with opened list.


Command button

Last edited: 10/5/2017 11:51:34 AM

With a command button, you can initiate an immediate action.

Command buttons are shown with a text describing the action that will be performed when it is clicked, with an icon indicating the action or with both.

CommandButton

Figure 1: Command buttons as used in the modal Connect to Application Server window

While command buttons are used for immediate actions, more information might be needed to perform the action. If so and the button is shown with a text, this is indicated by an ellipsis at the end of the button label.

Some forms (usually modal forms) define a default command button that is invoked when the users presses the Enter key. A default button is invoked when pressing Enter even if the button does not have focus.

Many command buttons have an associated tool tip. Hover over the command button to display the tool tip.In this documentation we refer to command buttons with the label text of the button. E.g. click on Login.

Key | Meaning
Enter | Start the action associated with the command button. If the Button was defined as the default button Enter will start the action even if the button does not have focus.

Table 1: Keyboard shortcuts for command buttons


Context menu

Context menus are menus displayed when you right click on some object of the user interface. (or alternatively when pressing the Windows' context menu Keyboard button while the object has focus). Context menus provide access to a list of actions available for the element that is currently in focus.

Context menu might adapt to the status of the object for which it is displayed, i.e. some elements might be disabled or invisible.

ContextMenu

Figure 1: A context menu opened for a list element in the Connection manager


Labels

Last edited: 10/5/2017 11:51:34 AM

User interface text appears on the user interface of the Smart Client. This text includes control labels and static text. Control labels identify controls or provide additional information associated with a specific control. They are placed directly on or next to the controls. Static text, which is so called because it is not part of or associated with an interactive control provides users with detailed instructions or explanations so they can make informed decisions.

Most controls come with an associated control label. Control labels are usually placed left of the control. They describe the data displayed in the control and give the control a name. When we refer to specific controls in this Reference Manual we mostly use the name of the associated label. Control labels are usually placed left of the control they are associated with. The text shown by the control label ends with a colon.

DropDownList

Figure 1: A control label ('Communication protocol:') together with its associated control

If a control shows numeric data that is in a specific the unit will not be shown as part of the label but will be shown in the control.

In some cases the user interface provides additional information on a control by placing instruction labels below the control. These labels come along with a small icon identifying the label as instruction label and are also formatted differently.

InstructionalLabel

Figure 2: Instruction label


Date-time-offset

Last edited: 10/23/2017 8:11:34 AM

The Date-Time-Offset control is used to display and modify Date-Time-Offset values. The control consists of two elements The date-time box (Figure 1:1) allows to input or select a date and time value. The offset box (figure 1:3) is used to display and modify the offset of the date time value.

To select a date and time without actually typing the date and time value open up the picker (figure 1:2) and select the date and time value from there (figure 2). If you want to type the date time value just place focus on the date time picker and start typing. The date-time picker will parse the value as you type and will present suggestions for auto competition. To use the suggested value just press enter. Note that the date format is the format as provided by the operating system on which the Smart Client is run.

When you select a date (either by typing or by using the picker) the offset is is automatically calculated using the time zone of the Operating System on which the Smart Client is run. you can however modify the offset value manually if needed.

Typing in date and time values

The Date-Time-Offset control can parse keyed in values either in the short date time format defined by the used culture or in the military date time format derived from the short date time format of the used culture.

When keying in date time values the military time format is the most efficient way. Table 1 shows the examples of the short date time format defined by different cultures and the derived military date time format. For details about date and time format string please refer to chapter Date-time formatting.

Table 2 shows examples of date entry using military date time format (in culture German (Austria))

Culture | Short date time format | Military date time format
German (Austria) | dd.MM.yyyy hh:mm:ss | ddMMyy hhmmss
English (United States) | M/d/yyyy hh:mm:ss | MMddyy hhmmss
English (United Kingdom) | dd/MM/yyyy hh:mm:ss | ddMMyy hhmmss
Swedish (Sweden) | yyyy-MM-dd hh:mm:ss | yyMMdd hhmmss

Table 1: Date time formats used by the Date-Time-Offset controls in different cultures

Keyed in string | Parsed date time value
9 09 | 9th of current month, current year, at 12:00:00
095 0905 | 9th of May in current year, at 12:00
09059 090509 | 9th of May 2009 at 12:00:00
090509 1 090509 01 | 9th of May 2009 at 01:00:00
090509 015 090509 0105 | 9th of May 2009 at 01:05:00
090509 01053 090509 010503 | 9th of May 2009 at 01:05:03
0 | Current day, current month, current year at 12:00
˽1 | Current day, current month, current year at 01:00:00
˽01053 | Current day, current month, current year at 01:05:03

Table 2: Examples for date time value entry using military format using German (Austria) as culture.

If the control is configured to allow null you can set the value of the date-time-offset to null by deleting the date. If the control does not allow null values the value will be set to the current date if deleted.

The time parts shown by the control can be different depending on the context in which the control is used, following configurations are possible

·Date only

·Date and hour

·Date, hour and minutes

·Date, hour, minutes, seconds

DateTimeOffset

Figure 1: The date-time-offset control

DateTimeOffsetPicker

Figure 2: The date time picker


Drop-down list

Last edited: 10/5/2017 11:51:34 AM

With a drop-down list, you make a choice among a list of mutually exclusive values. You can choose one and only one option.

DropDownList

Figure 1: A drop down list as used in the Application Server Connections window

Drop down lists support locate as you type i.e. when the drop down list has focus and you start typing the item with a name beginning with those letters will be selected.

In many cases the list elements within the drop down list have associated tool tips. Hover over the list entry to display the tool tip, hover over the drop down list to see the too tip of the currently selected value.

If the drop down list allows setting a null value you can set it to null by pressing the Backspace key while the drop down list has focus.

Figure 2: The Clear selection command button within the drop-down list can be used to set the value of the control to null.

In this documentation we refer to drop-down lists as list or box (whichever is clearer) together with the label text.

Key | Meaning
Alt+down arrow | Display the items list.
Esc | Hide the items list
Arrow up, Arrow down, Page Up, Page Down, Pos1, End | Navigate through the items list
Backspace | Set the value to null (only if supported)
Crtl+E | Open element definition. If the list of elements shown in the drop down list can be modified by the user this keyboard shortcut opens the user interface for editing list elements.

Table 1: Keyboard shortcuts for drop down lists


Grid

Last edited: 10/5/2017 11:51:34 AM

A Grid is a control that is used to display or modify data in a tabular form. Depending on the context it is used in a grid can offer sophisticated functions for sorting, filtering and ordering data. Besides the grids content that is shown in rows and columns the grid can show following optional components: a grouping area (figure 1:1), column headers (figure 1:2), expander button (figure 1: 4) and expander regions (figure 1:5) and a split bar (figure 1: 6) .

Figure 1: Example of a grid control.

The Grouping area is used to group the displayed data by the values of one or more columns. Drag the header of the column you want to group by into the grouping area to define the grouping criteria. You can group by any number of columns. When grouped you can click on the grouping element in the grouping area to change the sorting of the grouping.

The column headers give the displayed column a name and can be used to sort by that column and to filter the displayed data by this column. Click on the column header to change sorting, click on the funnel symbol to open up the filtering dialogue. Column sizes can be changed by dragging the borders of a column header.

Expanders can be used to display or hide detail information about a single row.

The Split bar can be used to split the grid vertically. Both sub grids will show the same data but the horizontal scroll bar only applies to the right sub grid.

The grid can allow the selection of multiple rows. If so you can use the Keyboard and Mouse to select multiple rows, see table 1 for a description.

Task | Steps
Select multiple consecutive rows | Select first row, hold Shift and select last row with mouse click Select first row, hold Shift and use Up-Arrow or Down-Arrow
Select all rows | Crtl + A
Remove some some rows from selection | Ctrl + Left Click on selected row
Select multiple non consecutive elements Add rows to selection | Ctrl + Left Click on unselected row
Select all elements up | Crtl + Shift + Up Arrow
Select all elements down | Crtl + Shift + Down Arrow

Table 1: Selection of multiple elements in a grid with multi-select is enabled


Group box

Last edited: 10/5/2017 11:51:34 AM

A group box is a labeled rectangular frame that surrounds a set of related controls. A group box is a way to show relationships visually. A group box provides no functionality.


Image

Last edited: 10/5/2017 11:51:34 AM

An image control is a simple control for displaying a bitmap image.

Figure 1: An image control as used in the User Profile window


Info bar

Last edited: 10/5/2017 11:51:34 AM

Info bars are used to describe the contents shown in a window or in a part of a window. The text shown in info bars is not static but may change according to the context in which the window is opened.

If the Text in the info bar is too wide it will be truncated and an ellipsis will be shown. In that case the tool tip text will show the whole text of the info bar

Figure 1: An info bar control describing the contents of a tree view in the Presentation Template Explorer

Info bar with ellipsis

Figure 2: The same info bar as in Figure 1 but with not enough space to display the whole text.


Language picker

Last edited: 10/5/2017 11:51:26 AM

The language picker control is used to define the language for the associated control, i.e. to define the language to which the contents of the control are bound. The language picker is shown next to all controls that support multilingual data.

You can use the language picker to specify a string in different languages. Changing the selected language in the language picker control will show the data for that language in the associated text box control. Changes in the text box control will always be stored linked to the currently selected language.

In the language selection menu that opens when clicking on the language picker control, all languages supported Application Server languages and the special Invariant language are shown.

Selecting one of the supported application server languages will obviously switch the associated text box control to that language, i.e. the text box control will show the data stored for that language and and data entry or modification will be stored for that language.

The invariant language is a special language that can be used to specify data that will be used for all languages for which no language-specific data is stored. I.e. if you specify the content only for the invariant language the content will be used for any language.

Figure 1: The language picker with opened language selection menu.

Key | Meaning
Space | Open language picker menu

Table 1: Keyboard shortcuts for the language picker control


List view

Last edited: 10/5/2017 11:51:34 AM

With a list box, you can select from a set of values presented in a list that is always visible. With a single-selection list box, users select one item from a list of mutually exclusive values. With a multiple-selection list box, users select zero or more items from a list of values.

List boxes support locate as you type i.e. when the drop down list has focus and you start typing the item with a name beginning with those letters will be selected.

Key | Meaning
Home | Select first item.
End | Select last item.
Ctrl+Home | Move focus to first item without selecting.
Ctrl+End | Move focus to last item without selecting.
Ctrl+Arrow keys+spacebar | Allow discontinuous multiple selection of items (in multiple-selection list boxes only)
Any printable key or keys | Moves the selection to the item matching prefix letters in the beginning of the label.
Space | Selects the focused Element
Ctrl+A | Selects all Elements (in multiple-selection list boxes only)
Ctrl+Mouse Click | Select multiple elements (in multiple-selection list boxes only)
Shift+Mouse Click | Select ranges of items (in multiple-selection list boxes only)

Table 1: Keyboard shortcuts for list boxes

Figure 1: The features in the Feature browser are shown in a multiple-selection list box.


Menu

Last edited: 10/5/2017 11:51:34 AM

A menu provides a selection of actions that can be initiated by selecting one of its menu elements. Menus are used for context menus, menu buttons, and other controls

A menu consists of a list of menu items and optionally separators that are use to group related menu items. A submenu or cascading menu is a secondary menu that can be displayed on demand from within a menu. They are indicated by an arrow at the end of the menu label.

Toggle menu items are special menu items that are used for setting Boolean values, selecting a toggle menu item will toggle the value from true to false or from false to true. The current toggle state is indicated by the icon if the icon is a check the value is true if no icon is displayed the value is false.

If a menu item's label is displayed in bold face this item is the default item. The action behind the default item will also be executed when you double-click on the object for which this context menu is displayed.

ContextMenu

Figure 1: A context menu opened for a list element in the Connection manager


Menu button

Last edited: 10/5/2017 11:51:34 AM

Menu buttons are used to provide menus with a small set of related actions. Clicking on a menu button will bring up a menu of related actions from which you can select one.

MenuButton

Figure 1: Example of a menu button with the associated menu shown.

Key | Meaning
Enter | If menu is currently not shown, menu will be opened.

Table 1: Keyboard shortcuts for menu buttons


Radio button

Last edited: 10/5/2017 11:51:34 AM

With a radio button, you make a choice among a set of mutually exclusive, related options. You can choose one and only one option. Radio buttons are so called because they function like the channel presets on radios.

Key | Meaning
Space | Select the focused option

Table 1: Keyboard shortcuts for radio buttons


Pager

Last edited: 10/5/2017 11:51:34 AM

In many cases the Smart Client fetches data from the Application Server in Pages. I.e. the results for a query to the Application Server are separated into pages, each page containing a specific maximum number of elements. The Client will only fetch one page at a time and can therefore decrease loading time.

The user can brows through the pages with the Pager control, that is usually located beneath a list view or grid control.

The Pager has four command buttons to navigate to the first, the previous the next or the last page. Additionally you can jump to a specific page by typing the page number into the Page Text box. The label on the very right of the Pager control shows the number of available pages.

Figure 1: The Pager control.


Property grid

Last edited: 10/5/2017 11:51:34 AM

The property grid control provides a versatile user interface for browsing and modifying the properties of an object.

The property grid consists of following components

·Property categories (figure 1:1)

·Property labels (figure 1:2)

·Property editors (figure 1:3)

·Summary area (figure 1:4)

Properties are the data elements that are displayed by the property grid they consist of a property label and the property editor. The property editor is adapted to the data type of the property.

Property categories are used to group related properties. Categories can be expanded and collapsed so that the properties in that category are either visible or not. Categories can be nested i.e. one categories can be inside other categories. Property categories are optional i.e. not used in every property grid.

The summary area displays detailed information about the focused property or property category.

Figure 1: The property grid control as used in the Smart Client settings window.


Separator

Last edited: 10/5/2017 11:51:34 AM

The separator control is used to create regions in windows. Sizing separators can be moved with the mouse (left click, hold and move). Separators can be vertical or horizontal.

Separator

Figure 1: The separator control used in the domain explorer


Spin control

Last edited: 10/5/2017 11:51:36 AM

With a spin control, you can click arrow buttons to change incrementally the value within its associated numeric text box. The term spin box refers to the combination of a text box and its associated spin control.

While spin controls are used for numeric input, the input doesn't have to be a pure whole number. The input can be decimal numbers and it can have negative signs.

Since the spin control is based on the numeric text box controls the keyboard shortcuts defined there apply.


Switch

Last edited: 10/5/2017 11:51:36 AM

With a switch, you make a decision between two opposite choices i.e, true/false, yes/no etc. The switch label indicates the on state, the meaning of the off state is the opposite of the selected state.

Figure 1: A switch Control in off and on state

Key | Meaning
Space | Switch from off to on or vice versa

Table 1: Keyboard shortcuts for check boxes


Tabs

Last edited: 10/5/2017 11:51:36 AM

Tabs provide a way to present related information on separate labeled pages, tabs are container controls. Tab controls represent the tabbed manila folders used to organize information in filing cabinets commonly found in the United States.

The Smart Client uses Tabs in different layouts (placement of tab labels etc). Tabs might also be nested.

Figure 1: Example for a horizontal tab as used in the User sessions window


Text box

Last edited: 10/5/2017 11:51:36 AM

With a text box, you can display, enter, or edit a alphanumeric text or numeric value. Text box come in different flavors displayed in Table 1.

Numeric text boxes may allow to enter and display null values. To enter a null value in a text box that supports it, select the whole text in the input box and hit the Del key. Doing so in numeric input text boxes that do not support null values will set the value to zero. Numeric text boxes may show the unit of the number.

When receiving focus the text in a text box is either fully selected or the caret is placed at the end of the text. The decision of this behavior was done with the intended usage in mind.

Flavor | Description
Single line text input | A single-line text box used to enter or edit short strings. No line breaks can be entered.
Multi-line text input | A multi-line text box used to enter or edit long strings. Line breaks can be entered.
Numeric input | A single-line text box used to enter or edit numerical values.
Password input | A single line text box used to enter passwords. The actual letters typed are not shown.
Single line text output | A single-line read-only text box used to display short strings
Multi line text output | A multi-line, read-only text box used to display long strings.
Numeric text output | A single-line text box used to display numerical values

Table 1: The different flavors of the text box control

Key | Meaning
Ctrl-A | Select all text

Table 1: Keyboard shortcuts for radio buttons

TextBox

Figure 1: Example of text boxes for alphanumeric text. Last Name is a single line text input, Description a multi line text input

TextBoxNumeric

Figure 2: Example of a numeric text box allowing the entry of seconds


Toolbar

Last edited: 10/5/2017 11:51:36 AM

The tool bar is a container control that is placed on top of many windows. It is mostly used to provide access to commands that apply to the whole window.

If the toolbar includes more controls that can be shown due to the limited window width the hidden toolbar controls can be selected by clicking on the drop down arrow at the right border of the toolbar (figure 1: 1)

The controls shown on the toolbar may change depending on the current context. E.g. if the window has a tabs controls that refer to a specific tab will be shown only when that tab is active.

Toolbar

Figure 1: The toolbar of the view explorer window


Tool tip

Last edited: 10/5/2017 11:51:36 AM

An tool tip is a small pop-up window that concisely describes the object being pointed to, such as descriptions of toolbar controls, icons, graphics, links, and other objects. Tool tip are a form of progressive disclosure, eliminating the need always to have descriptive text on screen.


Tree view

Last edited: 10/5/2017 11:51:36 AM

With a tree view, you can view and interact with a hierarchically arranged collection of objects, using either single selection or multiple selection.

In a tree, objects that contain data are called leaf nodes and objects that contain other objects are called container nodes. A single, top-most container node is called the root node. Users can expand and collapse container nodes by clicking the expander icons.

Nodes and leaves can provide an associated context menu, this context menu can have a default entry that is initiated when you double click on the node or leaf.

Key | Meaning
Asterisk (*) on numeric keypad | Display all sub-items under the selected item.
Plus sign (+) on numeric keypad | Display the sub-items directly under the selected item.
Minus sign (-) on numeric keypad | Collapse the items directly under the selected item group.
left arrow | Collapse the current selection (if it is expanded) and move focus to the group leaf root.
right arrow | Display the sub-items directly under the selected item (if it is collapsed).
Alt+left arrow | View the previous group.
Alt+right arrow | View the next group.
Ctrl+up arrow | Scroll the view without change of the selection.
Ctrl+down arrow | Scroll the view without change of the selection.
Any printable key or keys | Moves the selection to the item matching prefix letters in the beginning of the label

Table 1: Keyboard shortcuts for tree view controls

TreeView

Figure 1: A tree view control as used in the Domain Explorer


UConfiguration property grid

Last edited: 12/14/2017 7:56:44 AM

The UConfiguration property grid is a control used for displaying modifying the settings in a UConfiguration.

The control shows the hierarchically structured groups (figure 1:1) of a UConfiguration and the settings within these groups. For each type of setting the UConfiguration the UConfiguration property grid provides specific property editors (figure 1:2)

The Summary area (figure 1: 3) provides a quick help on the currently highlighted setting or group.

Figure 1: The UConfiguration property grid as used in the Time-Value chart configuration


User and user groups

Last edited: 10/5/2017 11:51:36 AM

This control is used to select users and user groups and is used whereever you assign something to users and user groups. Figure 1 shows the control as it is used in the Approval Template Editor window.

To add users or user groups to the list you simply drag those users or groups from the User & User Groups window. Multiple users or groups can be dragged at the same time. To remove users or user groups select the items in the list you want to remove and hit the Del key or choose Delete from the context menu.

To see more details of an element in the choose Open form the context menu of the item, this will bring up the User information window or the group editor window.

Figure 1: The User an user groups control


%Text%

Navigation: Smart Client > General Information >

Control blocks

Last edited: 10/5/2017 11:51:12 AM

There are some combinations of controls that are used repeatedly throughout the Smart Client and have the same behavior everywhere. Control blocks group these combinations into reusable units. This chapter describes the control blocks used by the Smart Client.


Visual appearance

Last edited: 10/5/2017 11:51:36 AM

The visual appearance Control container is used for defining the visual appearance properties of some object. It consists of several controls that define how the object should be presented on charts, maps etc.

VisualAppearance

Figure 1: The Visual Appearance control


Static time span

Last edited: 10/5/2017 11:51:36 AM

This control block is used for defining a static time span, i.e. a time span starting at a fixed point in time and ending at a fixed point in time.

StaticTimespan

Figure 1: The static time span control block


Dynamic time span

Last edited: 10/5/2017 11:51:34 AM

This control block is used for defining a dynamic time span. It shows controls for all settings that define a dynamic time span.

DynamicTimeSpan

Figure 1: The dynamic time span control block


%Text%

Navigation: Smart Client > General Information > Control blocks >

Observation Filter

Last edited: 10/5/2017 11:51:30 AM

The observation filter control block is used in different places to define an observation filter used by the application server to limit the observations shown or used by some process.

The actual layout of the control depends on which parts of the observation filter are enable din the context that the control block is shown with. E.g. an axis filter is not available for features that have no spatial support on observations.

With the Filter type box in the time filter area you can select which kind of time filter will be used. Depending on the selection either a control block for static or dynamic time filter will be shown.

With the Filter type box in the axis filter area you can select which kind of axis filter will be used. Depending on the selection either a control block for a static or for a dynamic axis filter will be shown.

Figure 1: The observation filter control.


%Text%

Navigation: Smart Client > General Information >

Basic concepts

Last edited: 10/5/2017 11:51:06 AM

Following chapter introduce some very basic concepts of the Smart Client.


%Text%

Navigation: Smart Client > General Information > Basic concepts >

Disconnected data

Last edited: 10/5/2017 11:51:14 AM

When the Smart Client works with the Application Server it does so by using the Services provided by the Application Server. When consuming a service the Smart Client connects to the Application Server provides the data needed to access the service and retrieves the result of the service call. After that the connection to the Application Server is closed again. I.e. there is no continuous connection between the Smart Client and the Application Server. This approach is very common in internet enabled applications and it has several implications you should be aware of.

Last save wins

When two Smart Clients modify the same entity on the Application Server by loading the entity data modifying it locally and the saving it again, the version of Smart Client who saves last will be the one that will be persisted on the Application Server. I.e. when loading the data of an entity to the Smart Client that data is not locked on the server, but can be modified simultaneously by different clients.

Errors with non existing data

When the Smart Client modifies data of an entity it first loads the data from the Application Server modifies it locally and then calls another Application Server service to save the modified data. In the meantime between loading and saving other clients might have modified the data of the same entity or might have modified data of other entities that this entity refers to. If these other clients deletes the modified entity or deletes an entity the modified entity refers to this will lead to errors when the Smart Client tries to save the data.

Client must save changes

Changes the Smart Client applies to data are only applied locally. To post this changes to the Application Server the Smart Client has to call another Service of the Application Server. I.e. unsaved data will be lost if the Smart Client is not closed gracefully or if the user decides to cancel data modifications. If therefore you modify data on the Smart Client you can cancel the modification by simply closing the window in which modifications were made without saving.

Reload from server button

Many forms have a reload data from Application Server button in the Toolbar. This will reload data from the Application Server. If not saved local changes will be lost when reloading data from the Application Server.

Figure 1: The Reload button in the toolbar of the View Explorer


%Text%

Navigation: Smart Client > General Information > Basic concepts >

Asynchroneous operation

Last edited: 10/5/2017 11:51:04 AM

The Smart Client calls Application Server services mostly asynchronously. That means that a call to the Application Server does usually not block the user interface. If a single window is waiting for the response of the Application Server only that window will be blocked and you can still work with other windows.

Actions that are supposed to take a longer time will always be started as job. I.e. the creation of a report will be started as job on the Application Server and the Report window will never be blocked.


%Text%

Navigation: Smart Client > General Information > Basic concepts >

Saving changes

Last edited: 10/5/2017 11:51:34 AM

Any window in the Smart Client can have pending changes, i.e. changes that are not yet saved on the Application Server. A window that can have pending changes will always have a Save button in its toolbar.That save button is only enabled if there are pending changes.

When you click on the Save button in a windows Toolbar the changes made to the data currently displayed in that window will be posted to the Application Server. If the changed data is valid and if you have the appropriate permissions the data will then be persisted by the Application Server. The Save button will then be disabled. If the save operation fails the Save button will stay enabled. In case saving fails you will be notified with an output message. The Keyboard shortcut for persisting the modified data in the current window to the Application Server is Crtl+S.

The Save button in the Ribbons Quick Access Toolbar (figure 2) will save all pending changes in all currently open windows. This button is also only enabled if there are any pending changes.

When you close a Window, when you exit the Smart Client or when you disconnect from a database the Smart Client will check if there are any windows with pending changes. If so a modal window will be shown that lists the name of all windows with pending changes. You can then choose to save all pending changes, to revert all pending changes or to abort closing the window, exiting the Smart Client or disconnecting from the Application exit.

In case of an ungraceful shutdown of the Smart Client all pending changes will be lost.

Figure 1: The save button in the Feature Editor window

Figure 2: The Save button in the Ribbons Quick Access toolbar

Figure 3: The confirmation message shown for pending changes


%Text%

Navigation: Smart Client > General Information > Basic concepts >

Output messages

Last edited: 10/5/2017 11:51:30 AM

Output messages are pieces of textual information the Smart Client wants to present to the user to keep the user informed about the actions of the Smart Client, the Application Server or other parts of the Redbex software system. For example output messages are used to display messages included in the result of a service request to the Application Server (server feedback messages).

The Smart Client has different possibilities to show Output messages. The Output Message window is the central place where all issued output messages will be displayed. The Status bar displays only the last view issued issued message.

Display | Usage
Output Messages window | All issued output messages are shown in the Output Messages window
Status bar | The status bar shows only the last issued message and shows the last 5 issued messages in a popup when the mouse hovers over the status bar.
Info window | Output messages with an interruptiveness of Draw attention are displayed as non-modal info window.

Table 1: Different displays of output message and their usage.

Property | Description
Source | The source that originally issued the message. Possible values are: •Application Server •Smart Client
Severity | Severity of the message. Possible values are •Information: Information that might be useful for the user. •Warning: Information about an event that is important for the user. •Error: Information that tells the user that something did not work as expected.
Interruptiveness | The interruptiveness defines how "interruptive" the message shall be. Note that severity and display priority are not the same. There might be a message with low severity that should still be highly interruptive. The other way round a message might have hight severity but low display priority. Following display priorities are supported: Do not disturb Draw attention
Timestamp | The date and time when the message was issued
Message text | The message text
Action log | Optionally a message can include an action log that gives more details to the user.
Actions | An output message might contain actions that the user can trigger.

Table 2: Properties of an output message


%Text%

Navigation: Smart Client > General Information >

Globalization, Localization

Last edited: 10/5/2017 11:51:22 AM

Redbex is designed to run in an global environment where the Application Server is not necessarily in the same culture as the Smart Client, where different Clients want to use different languages etc.


%Text%

Navigation: Smart Client > General Information > Globalization, Localization >

Smart Client language

Last edited: 10/5/2017 11:51:42 AM

The Smart Client supports different languages for the user interface. Currently these are English, German and Swedish.

Which of these supported interface languages will be loaded when the Smart Client starts depends on the Smart Client culture setting in the Smart Client settings. If the culture set there uses English, German or Swedish as language then the user interface language of the Smart Client will be set to that language. If the Smart Client culture is set to a culture with a language not supported by the Smart Client English will be used as User interface language.


%Text%

Navigation: Smart Client > General Information > Globalization, Localization >

Culture settings

Last edited: 10/5/2017 11:51:12 AM

Each culture has different conventions for displaying dates, time, numbers, currency, and other information. The Smart Client will use culture settings defined by your Windows Operating System configuration in the Regional and Language dialogue.

Therefore if you want to use different formatting for date, time, numbers and other culture specific data modify your settings in the Regional and Language dialogue and (re)start the Smart Client afterwards.


%Text%

Navigation: Smart Client > General Information >

Connection files

Last edited: 10/5/2017 11:51:12 AM

When installed the Smart Client registers files with the extension .RedbexConnection as files to be opened with the Redbex Smart Client.

If installed with the Full Setup the extension is registered for all uses on the computer, with the Light and Portable Setup the extension is registered only for the use installing the Smart Client.

.RedbexConnection files contain information about a Redbex Application Server connection i.e. the same information that you enter manually when creating an Application Server Connection in the Application Server Connections window. Passwords are never stored with .RedbexConnection files.

When opening a .RedbexConnection file (e.g from Windows Explorer) the Smart Client is opened and the contents of the connection file are passed to the Smart Client.

If there no stored Application Server connection with the same server name , instance name, protocol, port number, and user name the Smart Client adds a new connection to the stored Application Server connections. If the contents of the Redbex Connection file define the connection as default connection the newly created Application Server connection will be set as the default connection.

Regardless if the connection specified in the .RedbexConnection file is already in the list of stored Application Server Connections of the Smart Client the Smart Client will then choose this connection and will present the Connect to Application Server window.

Creating .RedbexConnection files

.RedbexConenction files can be created from by exporting a connection from the Application Server Connections window, or from the User and User Groups Window..RedbexConnection files are plain XML files that can also be created or modified manually.


%Text%

Navigation: Smart Client > General Information >

Auto login

Last edited: 10/5/2017 11:51:04 AM

For the comfort of a user the login to the Application Server can be done automatically whenever the user starts the Smart Client. Following conditions have to be met for Auto-Login to work.

·An Application Server Connection must me marked as Default.

·The Smart Client Setting "No auto login" must be set to false

·The Application Server Connection marked as default must have a stored user name and password


Backstage View

Last edited: 10/5/2017 11:51:06 AM

This chapter describes the various elements of the Backstage View. Selecting the Backstage tab of the Ribbon (Figure 1:1) opens the Backstage View. Note that in contrast to all other tabs on the Ribbon, selecting the backstage tab when the Backstage View is opened will close the Backstage View and take you back to the previously selected tab.

The Smart Client uses the Backstage View to expose functionality that mainly related to the Smart Client itself and not to the Application Server or to services the Application Server provides.

On the left-side of the Backstage View is the Backstage Menu containing of items that can be commands initiating an action (such as Connect and Disconnect) or tabs that will show more information or other commands in the Backstage View's detail area when selected. as shown in figure 1.

Selecting a command either on the Backstage View menu or in the detail area will immediately close the Backstage View and execute the action associated with that command.

Table 1 lists and describes the commands and tabs available in the Backstage View Menu.

Figure 1: The Backstage View with the Smart Client Administration Tab opened.

Command |
Connect | Enabled only if the Smart Client is currently not connected to an Application Server. This command will bring up the Connect to Application Server window.
Disconnect | Enabled only if the Smart Client is connected to an Application Server. This command will disconnect the Smart Client from the Application Server.
Application Server Connections | Brings up the Application Server Connections Window, where you can define new Application Server Connections or modify existing connections.
Smart Client Administration | This tab provides access to commands that are used for configuring and managing this installation of the Smart Client. It also displays some information about the Smart Client version and local resources used.
Support | This tab provides access to support options for Redbex
Exit | Exits the Smart Client

Table 1: Commands available in the Backstage view


Smart Client Administration tab

Last edited: 12/12/2017 6:14:10 AM

The Smart Client Administration tab shows mainly two columns. Column one provides access to several commands that are helpful for configuring and administrating the Smart Client, table 1 lists and describes the provided commands.

In the second column some information about the Smart Client, and the connected Application Server is displayed. The Smart Client Version (figure 1:1:) shows the version of this installation of the smart client. The Current session area (figure 1:2) gives information about the current connection to the Application Server. The Smart Client directories (figure 1:3) section shows the directories the Smart Client uses.

Command | Description
Smart Client Settings | Opens up the Smart Client Settings window.
Reset window layout | Resets the windows layout. Effective only after restarting the Smart Client.
Clear download directory | Deletes old files in the local download directory, i.e. files that were downloaded before the Smart Client was last started. The download directory holds all files downloaded from the Application Server.
Clear file cache directory | If the client downloads files from the server in the background.
Clear map cache directory | Clears the directory that the Smart Client uses to cache raster images downloaded from online Map Services (WMS, Google, Bing, Open Street Maps etc.)
Clear client side permission cache | Clears the client side permission cache.
Smart Client Update check | Checks if a new Version of the Smart Client is available. If a later version is available you will be provided a download link. If not an appropriate output message is shown.
Distribution Server Connection Check | Checks if the Smart Client can build up a connection the Distribution Server. The result of the connection test is shown as output message.

Table 1: Commands available from the Smart Client Administration Backstage tab

Figure 1: The Smart Client Administration Backstage tab.


Support tab

Navigation: Smart Client > Backstage View >

Smart Client Administration tab

Last edited: 12/12/2017 6:17:28 AM

The Support tab shows mainly two columns. Column one provides access to several support options, table 1 lists and describes the provided commands. The second column shows some general support information.

Command | Description
Redbex web page | Opens up the Redbex web page
Redbex support ressources | Opens the web page that links to all support resources.
Service desk | Opens the Redbex service desk web page
Desktop sharing | Opens the Remote Support Client, a small tool that will allow supporters to look at your monitor.

Table 1: Commands available from the Smart Client Administration Backstage tab

Figure 1: The Support Backstage View tab.


Windows

Last edited: 10/5/2017 11:51:40 AM

The following chapters describe each of the windows available in the Smart Client. These chapters focus on the most important aspects of each window, and do not describe each control in detail. Most windows use the services provided by the Application Server therefore we link the appropriate chapters within the description of every window.


Common

Last edited: 10/5/2017 11:51:10 AM

This Chapter describes windows that are either accessible through the ribbon menu's Common tab or can be opened from other windows but are all used for some common tasks in the Smart Client.


Projected System

Last edited: 12/14/2017 7:45:28 AM

This document window is used to display and modify a projected coordinate system. You can open the window from the Coordinate Systems window.

The Name text box is a mandatory and shall give the coordinate system a unique identifier. Note that while the EPSG code is a separate property of each coordinate system you will probably want to include that code also in the name to make a coordinate system name unambiguous.

In the Linear unit text box you can describe the used measurement unit. This value is descriptive only. The unit used for converting data between different vertical coordinate systems is encoded in the Proj.4 definition.

The Proj.4 definition is the formal definition of the projected coordinate system given in the syntax of the widely used Proj.4 coordinate transformation library. The given proj4 definition will undergo a syntactical check before the projected coordinate system is saved, you cannot save coordinate systems with an invalid or empty Proj.4 definition.

Figure 1: The Coordinate System window.


Coordinate Systems

Last edited: 12/14/2017 7:47:56 AM

The Coordinate Systems window lists available horizontal coordinate systems, i.e. geographic and projected systems. The window can be opened from the Common tab of the Ribbon.

All users can list the available coordinate systems. To add modify or delete coordinate systems you need the system permission Manage coordinate systems (24).

The list view shows the defined coordinate systems with their Name, Type (geographic or projected) and description. Coordinate systems that were predefined by Redbex and cannot be modified or deleted are designated with a shield icon (figure 1:1)

By selecting the toolbar toggle buttons Show geographic coordinate systems and Show projected coordinate systems in the window's toolbar (figure 1:2), you can filter the list. Note that if none of these toggle buttons is selected the list will be empty. Each element in the list view will show the Name of the coordinate system and its description as well as the type of the coordinate system (Geographic or Projected).

From the context menu of a list element you can select Edit to open the Coordinate System window for that coordinate system. Alternatively just double-click on an entry in the list.

To delete a Coordinate system select Delete from the context menu or hit Del key. Note that deleting a coordinate system will fail if the coordinate system is used as spatial reference system for some feature.

The digital elevation

To create a new coordinate system select either Add geographic coordinate system or Add projected coordinate system from the window's toolbar (figure 1:3). This will open the Coordinate System window.

Select Delete in the context menu of an axis to delete that axis. Note that deleting an axis will fail if the axis has an axis reference system that is used as spatial reference system by some feature. Deleting a coordinate system will delete any association with of a domain with that coordinate system.

Figure 1: The Coordinate Systems window.


Connect to Application Server

Last edited: 10/5/2017 11:51:36 AM

The Connect to Application Server window is a modal window that is used to establish a connection with a Redbex Application Server.

If at least one connection was defined in the Application Server Connections this window will be started automatically when the Smart Client starts up. If no connections are defined the Smart Client will show the Application Server Connections window on start-up. Alternatively this window can also be called from the Backstage Menu, if the Smart Client is not yet connected to an Application Server.

If a connection was defined as default connection in the Application Server Connections window that connection will be initially selected when this window is opened, if username and password were also stored along with the default connection and the Smart Client Setting Disable auto-login is not set the Smart Client will immediately connect to the Application Server.

When selecting a connection from the Connection list the window will display some details of the selected connection in the Connection info. This information shows the address of the Application Server, the name of the instance and the used communication port of the selected connection.

The Login button will become active if a connection was selected and a username has been specified. Clicking on Login will then initiate a login to the specified Application Server with the specified user credentials. If login succeed the window will be closed and the Smart Client will now load data for all open windows from the connected Application Server.

If login fails an output message will be created (see Output Messages) giving the reason of the login failure, and the connection window will stay open. If the login failed because the user with the specified name is forced to change his password, the window will be closed and the Connect to server with password change window will be shown.

If the connection can be established and the Application Server is not licensed or the Application Server uses a Demo license, a message box will be shown to remind you of the limitations that apply with unlicensed Application Server Installations or with Application Server Installations using a Demo license.

Clicking on the Cancel button will close the dialog without trying to connect to an Application Server.

If a connection is chosen for username and password are not stored the Save username and password check box is shown. If this check box is activated the provided username and password will be stored along with the selected connection when the login was successful.

Figure 1: The Connect to Application Server window


Connect to Application Server (with password change)

Last edited: 10/5/2017 11:51:36 AM

When the user who tries to connect to an Application Server from from Connect to Application Server window, is forced to change his password the Smart Client will automatically show this window.

The Connect to server with password change window is a modal window that asks the user for a new password. The window has the same behavior as the Connect to server window except it will change the password when the user selects Login.

Changing your password will fail if the new password does not match the password quality rules enforced by the Application Server or if the newly selected password is not different than the current password. In that case the window will not be closed after selecting OK. The reason for the failure will be written to the output window.

Figure 1: The Connect to Application Server with password change window


Geographic System

Last edited: 12/14/2017 7:47:20 AM

This document window is used to display a geographic coordinate system. You can open the window from the Coordinate Systems window.

The Name text box is a mandatory and shall give the coordinate system a unique identifier.

From the Vertical coordinate system drop down list you can choose one of the predefined vertical coordinate systems to associate with the current geographic coordinate system. From the Horizontal coordinate system drop down list you can choose one of the predefined geographic coordinate systems.

The Proj.4 definition text box cannot be edited but shows the definition of the selected horizontal coordinate system in the syntax of the widely used Proj.4 coordinate transformation library.

Figure 1: The Geographic Coordinate System window.


Domain focus

Last edited: 10/5/2017 11:51:14 AM

Redbex is build for managing data from multiple projects. While a domain in Redbex is more that just a project it is likely that in most installations real world projects will be implemented as domains on some level of the domain structure.

With the Domain Focus functionality the Smart Client can be configured in a way that allows for easier work flows when dealing with a single project at a time project.

By setting the focus to a specific domain the user can tell the Smart Client about his currently focused domain and the Smart Client can then assist the user in various places by filtering data or preselecting the focused domain. Table 1 shows the effects of setting a domain focus

Area | Effect
Domain explorer | The Domain structure is filtered. It shows only the focus Domain and all of its sub-domains.
View Explorer | The View Explorer will by default only show views that are associated with the focused domain (or one of its subordinate domains). The user has however the possibility to disable filtering views by focused domain.
Saving presentation templates | When saving a presentation template the Focus Domain is preselected.
Selecting domain on imports | When creating a new import definition the domain is preselected.

Table 1: Effects of setting the domain focus.

The domain focus can be set from within the Domain Explorer by choosing Set Focus to this domain from the context menu. Alternatively you can also use the drop down filter list from the Status Bar to select the domain focus.

It is also possible to set a default Domain Focus for each user. This Default Domain is stored with the user on the Application Server. Every user can set his own Default Domain, users with the System Permission Manage users and user groups (0) can also set the Default Domain Focus for other users.

If a default Domain Focus is defined in a user's profile the Smart Client will initially set the focus to this Domain, however as soon as the user set another Domain focus on the Smart Client this will override the Setting in the user's profile.

To release the domain focus you may also alternatively use the drop down filter list from the status bar or you can select Clear Domain focus from the Toolbar of the Domain Explorer.

The last used domain focus is saved locally when the Smart Client exits.

Figure 1: Setting (1) and releasing (2) the Domain Focus from the Domain Explorer

Figure 2: Setting (1) and releasing (2) the Domain Focus from the Status Bar


Downloads

Last edited: 12/12/2017 6:13:08 AM

The Downloads window is a tool window that shows file downloads from the Application Server that are currently active or already finished, it shows only downloads initiated since the start of the Smart Client. You can open this window from the Ribbon's Common tab.

In the list view each download is shown with the file name of the downloaded file, the list is ordered descending by the timestamp when the download was initiated. If a file with the same name as an already existing file in the download directory is downloaded from the Application Server the newly downloaded file will be automatically renamed.

As long as the file is in the progress of being downloaded a progress bar shows the current progress and a progress icon is shown on the left of the list view item. As soon as a download is complete a completed icon is shown.

Using the context menu on a completely downloaded file or by double clicking the list view item you can open the downloaded file i.e. you can advice Windows to open the downloaded file using the Application that is registered for that file type. For files that can be opened internally by the Smart Client the Open in Redbex menu entry will be shown.

Selecting Copy to... from the context menu of one or more selected files will create a copy of the downloaded file in a destination folder of your choice.

To remove a file (and to cancel download in case the download is still in progress) select Cancel and remove download from the context menu or a list view entry.

Select Open folder from the forms's toolbar to open the directory where the Smart Client stores all downloads.

If you downloaded files and restart the Smart Client those files will not be shown in this window since this window only shows the downloads that were initiated since the start of the Smart Client. However files downloaded in in a previous Smart Client run are still present in the download directory.

From the Administration Tab in the Smart Client's Ribbon Backstage menu you can delete all files in the download directory that were downloaded before the Smart Client was last started.

Figure 1: The Downloads Window


Event Schedule

Last edited: 10/23/2017 8:11:34 AM

The Event Schedule window is a window modal window that is used in different places to define the Event Schedule for a specific actions i.e. the points in time when actions shall be triggered. The window is used for defining the Event Schedules of various events, e.g. for stored job definitions and Observation Plans.

The Active switch is used to globally activate or deactivate the schedule.

With the Time zone Drop-down list you can choose the time zone in which the whole Event Schedule is defined. The drop-down lists time zones supported by the operating system on which the Smart Client is running. If the Time zone is not given the Application Server will interpret all date and time values of the event schedule in the time zone set on the Operating System of the Application Server.

The Recurring events tab allows the definition of the recurring events in the event schedule. The controls on this tab are exactly matching the definition of recurring events. Start date and End date can optionally be used to define a limit for recurring events.

To test your recurring event schedule you can select Get next 100 events. This will generate the next 100 events according to the currently set recurring schedule and will return the result as an output message. Note that this will not respect start date and end date or pauses.

On the Recurring events pauses tab you can pauses for recurring events, each pause must have a Start date and an End date and may have a Reason that describes why this event pause was created. To add a pause press the Add button on bottom of the List view. Do delete a pause right click the pause event ans select Delete from the context menu

On the Discrete events tab you can add discrete events to the event schedule. To create a discrete event select Add from the windows's tool bar. This will result in another date time picker displayed. Define the exact point in time using that date time picker. To delete a discrete event select Delete from the discrete events context menu.

Figure 1: The Event Schedule window with the tab for defining recurring events

Figure 2: The Event Schedule window with the tab for defining pauses

Figure 3: The Event Schedule window with the tab for defining discrete event dates


Favorites

Last edited: 11/8/2017 9:29:36 AM

The Favorites window is a tool window that displays the personal view and presentation template favorites of the current user. It can be used to save personal bookmarks that allow a quicker access to repeatedly used views and presentation templates. The Favorites window can be opened from the Common Ribbon tab.

The window displays either view favorites or presentation template favorites depending on the selected panel (figure 1:1).

Views

View favorites are created in the View Explorer window. From the Favorites window the favorite can be executed by double clicking the favorite or by selecting Execute view from the context menu of the favorite. To see the favorite view in the view structure of the View Explorer Window select Locate in View Explorer.

To rename the favorite or to change the description of a favorite choose edit in the context menu. When a view favorite is created from the View Explorer the favorite is named as the view and the view description (if any) is copied to the favorite's description. You can however edit both name and description of the favorite without affecting the original view.

To delete one or more view favorite select those favorites and then select Delete form the favorite's context menu or hit the Del key. Deleting a favorite does not affect the original view.

Presentation Templates

Presentation Template Favorites are created from the Domain Explorer. From the Favorites window the favorite presentation template can be directly executed by selecting the appropriate command from the context menu of the favorite.

To rename the favorite or to change the description of a favorite choose edit in the context menu. When a presentation template favorite is created from the Presentation Template Explorer the favorite is named as the template and the template description (if any) is copied to the favorite's description. You can however edit both name and description of the favorite without affecting the original presentation template.

To delete one or more favorites select those favorites and then select Delete form the favorite's context menu or hit the Del key. Deleting a favorite does not affect the original presentation template.

Figure 1: The Favorites window with the Views panel

Figure ": The Favorites window with the Templates panel


File Depot

Last edited: 10/5/2017 11:51:40 AM

The File Depot window is a tool window that shows all files in the current user's File Depot as well as all currently active uploads to the File Depot. You can start this window from the Ribbon's Common tab.

Every user has his own personal file depot on the Application Server and no user can see another users' files in their file depot.

The window shows two main areas the Currently uploading to depot area and the Depot contents area. The Currently uploading to depot area shows the files that are currently being uploaded from the local computer to the file depot on the Application Server. You can initiate an upload by dragging files from Windows explorer to the uploading area or by choosing Add files (Figure 1:2) or Add files from folder (figure 1:3) from the toolbar.

If a filter expression is defined in the windows toolbar Filter box (Figure 1: 4) only those files will be uploaded whose names match that regular expression - regardless of how the files to be uploaded were selected. Leave the box empty if you do not want to apply any filter.

A currently uploading file is shown in the Currently uploading to depot area, with its original file name and current upload progress. You can cancel an upload by selecting Delete from that upload's context menu. As soon as the upload of a file is completed, that file is shown in the Depot contents area.

Files shown in the Depot contents area can be downloaded again by selecting Download from the files' context menu. To delete files in the file depot select Delete from the files' context menu. Files in the Depot contents area can be dragged to other windows that need files (e.g. for importing). Note that the file sizes shown for files that were just uploaded to the Application Server are only shown after you click Refresh (Figure 1:1).

Figure 1: The File Depot window

The initial folder (figure 2:1) used when browsing after selecting Add files or Add files from folder as well as the custom places shown in Windows' Browse dialogue (figure 2:2) can be adjusted using the Smart Client common configuration.

Figure 2: Initial folder and custom places can be adjusted in the Smart Client Common Configuration.


Image Viewer

Last edited: 10/5/2017 11:51:38 AM

The Image Viewer is a document window that can display raster images (bitmap image) of different format. The Smart Client uses the Image Viewer to display raster files downloaded from the Application Server, e.g. when double clicking a raster image file in the Downloads window.

The Image Viewer window cannot be opened directly from the Ribbon. The modifications applied to the image displayed (e.g. rotation) is not saved back to the original file.

Figure 1: The Image Viewer displaying a raster image

The displayed image can be rotated using the rotate buttons in the Toolbar. Note that the rotation is never applied to the original file but if you choose to save the file locally (by selecting Save from the toolbar) the rotated image will be saved. You may scale the image by using the Scale slider or the Scale drop down shown in the lower left corner of the image. Alternatively you may user Ctrl + Mousewheel to zoom in our out.


Job Execution History

Last edited: 10/5/2017 11:51:38 AM

The Job Execution History window is a document window used to display and and manage the history of executions of a specific stored job definition. The window is started for a specific job definition from the Stored Job Definitions window.

The Info bar shows details about the stored job definition for which the history is currently shown. The Grid shows all executions of the job. You can open the job's log from the context menu of a grid row.

Figure 1: The Job History window


Job Management

Last edited: 10/5/2017 11:51:38 AM

The Job Management window is a document window used to display and modify active and archived jobs. The window can be opened from the Ribbons Common Tab.

The window is divided into two main areas, the top area shows lists of either active or archived jobs, the bottom area shows details about a selected job.

On the Active tab (figure 1) all currently active jobs are shown. When this tab is shown you can set an automatic reload interval in the tool bar. Activate the Automatic reload from Application Server toolbar toggle button and then set the Reload interval. The currently active jobs are shown in a Grid. The progress indicator displays the progress of the job when the list was last reloaded from the server. You can display a detailed progress by expanding a row.

The context menu on active jobs allows to Pause, Abort and Resume jobs. You can also display the job log of the selected job by selecting Job log from the context menu.

Jobs in an archived state are shown on the Archived tab. Since there might be thousands of archived jobs this tab only shows jobs in a specific time interval that can be set on the toolbar. By default this interval is set to the last 8 days. You can display the job log of a selected job by selecting Job log from the context menu.

The details area at the bottom of the form will display details of a selected job (either active or archived).

Figure 1: The Job Management window shown with active jobs

Figure 1: The Job Management window shown with archived jobs


Location Converter

Last edited: 10/5/2017 11:51:38 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Message center

Last edited: 10/5/2017 11:51:38 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Message Forwarding Rules

Last edited: 10/5/2017 11:51:38 AM

The Message Forwarding Rules window is a document window used to specify the forwarding rules that are used for forwarding Redbex internal messages via other delivery media. The window can be opened from the Ribbon's Common tab to show the current users personal message forwarding rules or from the ServerAdministration tab to show the global message forwarding rules.

Every user can create and modify personal message forwarding rules. For creating or modifying message forwarding rules of other users the system permission Manage message forwarding rules (28) must be granted.

The window shows two main areas. On the left side a list view shows all currently available forwarding rules. on the right side details of the selected forwarding rule are displayed.

To create a new forwarding rule select the appropriate delivery medium from the Add drop-down button in the window's toolbar.

To edit the filter settings for a specific rule, select the rule in the list on the left and modify the rule's filter accordingly.

Notes:

·Filtering for severity is always performed, choose lowest and highest severity in from and to to match any message

·If the filter expression is empty no filtering on message subject or body will be performed.

·To disable filtering for message source context set the Source context to null

·The Description is available for describing the reason or aim of the rule, it is not used in message filtering.

Figure 1: The Message Forwarding Rules Window


New Message

Last edited: 10/5/2017 11:51:40 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Output files

Last edited: 10/5/2017 11:51:40 AM

When the result of an operation on the Application Server is a file or a set of files these files are made available via output files. The Output files window provides the user interface that allows you to manage and download the output files stored on the Application Server.

The Actions list on the left the window shows the actions that resulted in output files in chronological order (latest is shown first). Selecting one of the elements in this list will show the files associated with this action in the files list on the right. One action might contain any number of files.

In the Actions list you can select multiple actions, the context menu for the selected actions allows you to delete these actions together with their files. In the Files list you can select files. The context menu provides the possibility to download the file. Alternatively you can just double click a file in the Files list to download it. Downloads will be handled in the Downloads window.

Figure 1: The output files window


Output messages

Last edited: 11/8/2017 9:31:18 AM

The Output messages window is a tool window that displays all issued output messages.

The source of an output message is encoded using the color of the message text, table 1 describes this color code.

The Output window will be automatically opened on the first start of the Smart Client.You can open the Output window from the Others group in the Common Ribbon tab. Alternatively you can open the window by double clicking an output message in the status bar

Color | Message source
Black | Messages resulting from a service call to the Application Server (server feedback messages).
Green | Messages issued by the Smart Client itself.

Table 1: Color code for messages in the Output window

The output messages in this window are sorted by issue date of the message in descending order, i.e. the topmost message is the latest. When a new message is written to the output window it is written in boldface, after a few seconds the text will return to non-bold face.

The output message severity is displayed as icon. Table 2 describes the severity levels for messages. The severity levels match the severity levels of server feedback messages. The output messages' display priority is not shown by the output messages window.

Severity | Description
Information | Information for the user.
Warning | Information about an event that is important for the user.
Error | Severe errors that should be noted by the user.

Table 2: Output window message severities

If a message includes an Action log, the severity icon will be overlayed by an action log icon (Figure 1:3). In that case the Action log can be opened by double clicking on the message or by selecting Show log from the context menu of the output message. This will open up a text viewer displaying the Action Log.

By selecting the Clear output messages (Figure 1:1) you can clear the contents of the output window. Clearing cannot be undone.

All messages currently displayed in the output window can be exported to an XML formatted file. Select Export Messages (Figure 1:2) and choose a storage location and name for the file.


PDF Viewer

Last edited: 10/5/2017 11:51:40 AM

The PDF Viewer is a document window that can display PDF files. The Smart Client uses the PDF Viewer to display PDF files downloaded from the Application Server, e.g. when double clicking a PDF file in the Downloads window.

The PDF Viewer window cannot be opened directly from the Ribbon. The modifications applied to the displayed PDF (e.g. rotation) are never saved back to the original file.

Figure 1: The PDF Viewer displaying a PDF file


Property Structure Configuration

Last edited: 10/5/2017 11:51:40 AM

This window allows editing the property structure configuration (PSC) of a property structure used in type specific feature data, type specific observation data, type specific sensor data, and extended sensor configuration data.

The window can be started from the context in which the property structure configuration is defined. I.e. from a feature in the Feature Explorer, from a feature type in the domain context, from a feature subtype in the domain context and from sensors in the domain context.

The info bar on (figure 1:1) will show the context to which the currently shown configuration applies.

The tree on the left of the window shows the property structure layout, i.e. all properties and property collections. Each property has an icon that shows the property type. Selecting a property or a collection in the tree will show the configuration of that property or property collection on the right of the window.

Which settings are available for a property depends on the property type. Available settings are grouped in different sections: Mandatory, Display settings, Default value, Validation rules, Visual appearance (see figure 1).

The Mandatory setting defines if a value must be given for this property in order for the property structure to be valid.

The Display settings provide some (property type specific) settings that influence how the property is displayed in the user interface. All property types have a sequence number setting and a hide setting. The sequence number setting can be used to influence the sequence in which the properties are displayed in the user interface. The Hide setting can be used to hide properties from the user interface. You can enable or disable all display settings with the Display settings checkbox.

The Default value section allows to define a default value for this property in newly created property structure instance. You can enable or disable the default value with the Default value checkbox.

The Validation rules section allows to define (property type specific) rules that have to be met by the value of this property for a property structure instance to be valid. You can enable or disable the validation rule with the Validation rules checkbox.

The Visual appearance section allows to define the visual appearance of this property when it is shown in charts, reports and other presentations. You can enable or disable the visual appearance settings with the Visual appearance checkbox.

All property collections have the same settings (see figure 2). The validation rules section allows you to set a minimum and a maximum count of collection members. If a property structure instance has more or less members in this collection it will be considered as invalid.

The Display settings section can be used to influence the visual appearance of the property structure in the user interface. The Sequence number specifies the sequence in which collections will be displayed. The hide checkbox can be used to hide the collection from the user interface.

Figure 1: The property structure configuration window showing details for a numeric property

Figure 2: Property structure configuration window showing details for a collection


%Text%

Navigation: Smart Client > Windows > Common >

Start page

Last edited: 10/5/2017 11:51:40 AM

The Start Page is a document window that can be configured to show various information. The Start Page is automatically opened whenever a user connects to an Application Server. If you do not want the Start Page to open automatically you can turn this behavior off with the Smart Client Setting Do not show Start Page.

The Start window can be configured to show different information by placing widgets on the Start Page and by configuring the settings for each widget. Users with the Permission Manage users and user groups (0) can define a default Start Page configuration will be shown to all users who did not configure the Start Page for themselves. The Default Start Page can opened and configured from the Ribbon's Administration Tab.

Widget | Description
Redbex News | Shows the RSS feed of the Redbex News Blog from: http://news.redbex.com
Redbex Server News | Shows an RSS feed that contains information for this specific installation of the Redbex. The URL of the RSS feed is configured in the Global Settings
Redbex Training Videos | Shows the RSS feed of the Redbex Training Videos Blog from: http://videos.redbex.com/
RSS Feed | Shows a user configurable RSS feed.
Advance Status | This Widget is specifically useful for Tunneling. It shows the Advance Status (progression of work) based on the given Position On Axis features.

Table 1: Available Widgets

Figure 1: The Start Page window.


Stored Job Definition

Last edited: 10/5/2017 11:51:40 AM

This document window is used to display and modify a stored job definition. You can open the window from the Stored Job Definitions window Note that you only define the job in this window, the schedule for the job is defined separately.

The General tab shows controls for data that is common to all job types. The ID, Job type and Owner controls are read-only. Note that the settings for Execution priority and Tread priority will only be respected if the job owner has the appropriate permissions. If these permissions are not granted the execution priority and thread priority will be automatically lowered on execution of the job.

The Configuration tab shows the job type specific configuration settings in a property grid. Pleas refer to the documentation of the job type of the currently modified stored job definition for an explanation of these settings.

On the Followup jobs tab you can define which jobs will be started as soon as this job is finished. To add a follow up job enter the id of th followup job in the toolbar and select Add.

The Event Schedule for the job (i.e. when the job will be executed by the Application Server) can be opened from the window's toolbar.

Figure 1: The Stored Job Definition window


Stored Job Definitions

Last edited: 10/5/2017 11:51:40 AM

The Stored Job Definitions window is a document window used to display and modify job definitions stored on the Application Server. The window can be opened from the Ribbons Common Tab. The window will display all job definitions that the current user owns or if the user has the System permission Manage jobs job definitions owned by any user.

The window shows the stored job definitions in a Grid. Double click a job definition or select Edit from its context menu to open up a Job Definition window where you can modify the job definition.

Using the context menu for a selected job you can also open the the Job History for the selected job.

You can delete one or more selected jobs by selecting Delete from the context menu.

Using Create stored job definition menu button you can create stored job definitions of different job types.

Figure 1: The Stored Job Definitions window


Text Template Editor

Last edited: 10/5/2017 11:51:40 AM

The text template editor is a modal window that provides a comfortable way of editing text templates.

The big text box that covers the upper area of the window can be used to manually type text templates.

The tree structure in the lower left part of the window gives structured access to variables, filters and logical expressions. The Variables node has two sub nodes one for common variables available with every text template, and one of variables available in the specific context the editor was opened for. Selecting one of the nodes in this tree structure will show the available items in the tree structure to the right. An item might have sub items. Double clicking an item in the item tree structure will copy the syntax for this template to the text template, i.e. to the current cursor position in the text box.

Figure 1: The text template editor


Text Viewer

Last edited: 11/8/2017 9:30:48 AM

The Text Viewer window is a document window that can display any textual information. The Smart Client uses the Text Viewer in may cases to display textual information from different sources.

The text window cannot be opened from the Ribbon since it always displays information that is available in a specific context. The displayed text in the text window cannot be modified.

Figure 1: The text window displaying an action log.

To save the displayed text to a file select the Save text to file button (figure 1:1) and specify the location and name of the file in the appearing save dialog. This will save the all of the displayed text as a UTF-8 encoded text file..

To copy the whole displayed text to the clipboard select Copy text to clipboard (figure 1:2), alternatively you can just select a part of the text and user Ctrl+C to copy it to the clipboard.


Validation Results

Last edited: 10/5/2017 11:51:40 AM

This document window shows the validation results of a specific validation run. You can start this window from the Validation Browser.

The window is separated into three vertical sections. The validation subject tree, the property structure tree and the violations list.

The validation subject tree shows all validation subjects that were validated in this validation run. The shown structure depends on the validation subject type. Next to each validation subject the subject tree shows the overall status of the validation for this subject.

Depending on the type of validation subject the context menu provides a context menu that allows to directly open the data of that subject.

The Property structure tree shows all properties and property collections of the property structure of the selected validation subject for which violations where found. For property collections each collection shows the Id of the collection property structure instance for which the violation was detected.

The Violation list shows all violations detected for the selected property or property collection.

Figure 1: The Validation Results window


Vertical Coordinate System

Last edited: 10/5/2017 11:51:40 AM

This document window is used for creating and modifying vertical coordinate systems. You can open the window from the Vertical Coordinate Systems window.

All users can read all defined vertical coordinate systems. To modify a coordinate systems you need the system permission Manage coordinate systems (24).

Note that if opened for a protected vertical coordinate system all controls in this window will be read-only.

Redbex has limited support for conversion of vertical coordinate systems (see chapter vertical coordinate systems for details) based on a simple unit conversion and a constant shift that you define in this window in the Conversion factor and Conversion constant text boxes.

The Linear unit defines the unit used for linear measurement (i.e. measurements of elevation) in this vertical coordinate system. It is common to not only show the unit of measurement when presenting elevation values but also an abbreviation of the reference (i.e. the vertical coordinate system). The Linear unit code can be used to define such an abbreviation for the current Vertical Coordinate system. E.g. m AA (Meters above the Adriatic).

Figure 1: The Vertical Coordinate System window.


Vertical Coordinate Systems

Last edited: 10/5/2017 11:51:40 AM

The Vertical Coordinate Systems window is a document window used to display the defined vertical coordinate systems. The window can be opened from the Ribbons System Administration Tab. The window will display all vertical coordinate systems. Note that vertical coordinate systems are defined globally and do not apply to a specific domain.

All users can list the available vertical coordinate systems. To add modify or delete coordinate systems you need the system permission Manage coordinate systems (24).

The list view shows the defined vertical coordinate systems with their name and description. Coordinate systems that were predefined by Pöyry Infra GmbH and cannot be modified or deleted are shown with a shield icon (figure 1:1)

Double click an element in the list view or select Edit from its context menu to open up the Vertical Coordinate System window, where you can modify the coordinate system.

You can delete the selected vertical coordinate system by selecting Delete from the context menu. Note that you cannot delete vertical coordinate systems that are used by any horizontal coordinate system.

To create a vertical coordinate system select Add from the window's toolbar, this will open the Vertical Coordinate System window for a new coordinate system.

Figure 1: The Vertical Coordinate Systems window


View Privilege

Last edited: 10/5/2017 11:51:40 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Content & Structure

Last edited: 10/5/2017 11:51:12 AM

This chapter describes Smart Client windows used for managing content data.


Alarm Viewer

Last edited: 11/8/2017 9:27:20 AM

The Alarm viewer is a document window used to display all pending (unacknowledged) alarms. This window displays alarms that are associated with the currently logged in user. If the current user has the global permission Acknowledge all observation alarms all pending alarms will be shown. The window can be opened from the Common ribbon tab.

The window displays a grid with all pending alarms, remember that you can use the grids sorting and grouping functions to get a better overview of your pending alarms. To acknowledge pending alarms you can select one or more grid rows and then select Acknowledge from the context menu. This will open up a window modal dialogue from which you can acknowledge the selected alarms (see figure 2).

The alarms displayed in the grid can be filtered by trigger date and by severity. The filter conditions can be defined in the area above the grid. The toolbar toggle button Show / hide filter area (figure 1: 1) can be used to hide the filter area if not needed.

With the Auto reload from Application Server toolbar toggle button you can advice the Smart Client to automatically reload the list of pending alarms in the defined interval.

Figure 1: The Alarm viewer window

Figure 2: The Alarm viewer window with the window modal window Acknowledgement opened


Approval

Last edited: 10/5/2017 11:51:04 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Approval Template

Last edited: 10/5/2017 11:51:36 AM

The Approval Template window is a document window used for showing and modifying a approval templates. You can open the Approval Template window from the Approval Templates window or from the context of a domain in the Domain Explorer. Multiple instances of this window can be opened but only one instance for a specific approval template.

The window shows two tabs General and Stages. On the General tab (figure 1) some general information about the Approval template can be set. The Domain field is read-only and shows which domain this template is assigned to. The domain assignment is defined when the approval template is created. Name and Description fields help you to identify the approval template and should describe the usage of the template.

The Approval process security defines what a user has to do to approve in a stage of the process.

The Stages tab (figure 2) shows all stages in that approval template. On the left side of the tab you see the ordered list of stage. New stages can be added by selecting Add from the toolbar. The stage order can be changed by drag and drop within the stages list. When an approval process is started based on this template the stages will be executed exactly as the sequence in this list. Right to the stages list you see the details of the currently selected stage. Name and Description should explain the usage of the stage. The Approval time span defines how long users have time after the stage was started to fulfill their approval obligation in this stage. Depending on the setting of Auto approve on overdue the stage will then be either automatically approved or the process will expire. If you do not want any approval time span i.e. if you allow an unlimited time for approval you set the approval time span to 0:0:0:0.

The Fulfillment criteria defines how many users out of the users defined in Obligations have to approve so that the stage is approved. Setting this to means that all of the assigned users have to approve. Note that since you may assign user groups to the obligations the actual count of obligations is only evaluated when an approval process is started. The Application Server however will take care that the fulfillment criteria is never higher than the actual number of user with obligation to approve.

In Obligations (a user and user groups control) you select the users and / or user groups that have the obligation to approve this stage in the process.

Figure 1: The Approval Template window's general tab

Figure 2: The Approval Template window's stages tab


Approval Template Assignment

Last edited: 12/14/2017 8:16:08 AM

The Approval Template Assignment window is a document window that shows an approval template assignments (which is a feature directive). You can open this window from the Feature directives window. Multiple instances of this window can be opened at the same time but only one window can be opened for one specific approval template assignment.

The info bar of the window shows the feature on which the approval template assignment directive is defined.

The Template for feature drop down list lets you choose which Approval template shall be used for the features in the feature context shown in the info bar. The Template for observations drop down list lets you choose the approval template for observations.

If you select Autostart feature approval an approval process will be automatically started with the selected template as soon as a feature in a matching context is set to ready. The same goes for Autostart observation approval.

Figure 1: The Approval Assignment window


Approval Templates

Last edited: 10/5/2017 11:51:36 AM

The Approval Templates window is a document window that shows a list of all approval templates available in a specific domain. You can open the approval templates window from the context menu of a domain in the Domain Explorer. Multiple instances of this window can be opened but only one instance for a specific domain.

The info bar (figure 1:1) shows the domain for which the window is opened.

Each entry in the list of Approval Templates shows one approval template that is defined in the domain the window was opened for or in a parent of this domain. The actual domain in which a listed approval template is defined is shown with each entry (see figure 1:2 and figure 1:3)

Selecting Add in the window's toolbar brings up the Approval Template Editor window for creating a new template in the domain shown in the info bar. Double clicking an existing element in the list or selecting Edit from the elements context menu brings up the Approval template editor for that template.

Selecting Delete from an elements context menu will delete the approval template. Note that deleting an approval template is not possible if the approval template is used in some Approval template assignment. The template list also allows to select multiple elements at once and delete all of them.

Figure 1: The Approval Templates window


%Text%

Navigation: Smart Client > Windows > Content & Structure >

Associated Data

Last edited: 10/5/2017 11:51:36 AM

The Associated data window is a tool window is used to view and edit Associated Data stored for features and observations. The window can be opened from the Content & Structure Ribbon tab.

The window will always show the associated data for the latest selected feature or observation. It will react to selection changes in the feature explorer, as well as in the feature editor windows and other places in the Smart Client User interface.

The windows Info bar will always show for which feature or observation associated data is currently shown (figure 1:1).

The window shows four tabs that are used for displaying and modifying the four different types of associated data Attachments, Comments, Links and Associated Features. If there is associated data for one of these types the tab will display the count of associated data (figure 1:2)

The window's toolbar will change according to the currently active tab. The information bar shows the number of attachments, comments and Links

Figure 1: The associated data tool window


Attachments

Last edited: 10/5/2017 11:51:36 AM

The Attachments tab in the Associated data window view and edit attachments stored for features or observations. The tab shows the attachments stored for the currently active feature, or for the currently selected observation in the Feature editor.

The tab provides two different views that can be switched by selecting either the Grid view or the Thumbnail view toolbar button (figure 2:1).

The grid view shows a list of all attachments, where each attachments is listed with the original file name and the file size. The attachment tag is shown as the leftmost column. The sequence number column can be used to sort the attachments by applying numbers.In the grid view you can directly edit the sequence number.

The thumbnail view shows the thumbnail images that were created by the Application Server when the attachment was created. Note that the Application Server cannot create thumbnails for all kinds of files see chapter Attachments for more details. Files for which the Application Server could not create a preview will be shown with a default preview image (see figure 2:2)

Adding a new attachment to a feature or observation can be simply accomplished by dragging a file from the file depot window to either the grid view or the thumbnail view.

To delete one or more attachments select the attachments in either grid view or thumbnail view and hit the Del key or use the context menu and select Delete.

To download a specific attachment you can just double click the attachment in either grid view or thumbnail view. Multiple attachments can also be downloaded by selecting them and then choosing Download from the context menu.

The tag assigned to the selected attachments is is shown in grid view as well as in thumbnail view. You can choose a tag for an attachment from the context menu or from the Attachment details window modal window.

Sequence number, Description and Tag of a single selected attachment can be edited in a separate window modal window, as shown in figure 4. Choose Edit from the attachment's context menu to bring up this window modal window.

Figure 1: The Attachments window with the grid view

Figure 2: The Attachment window with the thumbnail view

Figure 3: Context menu of the attachment browser.

Figure 4: The window modal window to edit Description tag and sequence number.


Comments

Last edited: 10/5/2017 11:51:36 AM

The Comments tab in the Associated Data window shows comments stored for a feature or observation and allows to manage those comments. The tab shows the comments stored for the currently selected feature, or for the currently selected observation.

The grid lists all available comments. If a comment consists of multiple lines the Comment column will only show the first line, you can use the row expansion to show the full comment (figure 1:1)

To create a new comment select Add from the toolbar. This will open a window modal dialogue that allows you to specify the text for the new comment. Note that the comment will always stored with a reference to the user who created it and the point in time when it was created.

To revoke a comment select Revoke from the context menu.

To delete a comment or a set of events mark the grid rows and chose Delete from the context menu. Note that deleting comments needs the feature permission Manage (7) on the feature the comment belongs to (either directly or via an observation)

Figure 1: The Comments window.


%Text%

Navigation: Smart Client > Windows > Content & Structure > Associated Data >

Links

Last edited: 10/5/2017 11:51:36 AM

The Links tab in the Associated Data window shows links stored for a feature or observation and allows to manage those links.

The grid lists all available links with their URL and their description. You can directly follow the linke by clicking the URL. To create a new link select Add from the toolbar. This will open a window modal dialogue that allows you to specify the URL and description of the new link.

To delete a link or a set of links mark the grid rows and chose Delete from the context menu.

Figure 1: The Link tab in the Associated Data window.

Figure 2: The Link tab in the Associated Data window with the window modal window to modify a link.


%Text%

Navigation: Smart Client > Windows > Content & Structure > Associated Data >

Associated Features

Last edited: 10/5/2017 11:51:36 AM

The Associated Features tab in the Associated Data window shows feature associations stored for a feature or observation and allows to manage those associations.

The list shows all associated features their Name and some additional information (comparable to the way features are presented in the Feature Explorer window). You can directly open the associated feature from the list by selecting the quick open button that appears when you hover a feature.

To create a new feature association first select edit from the window's toolbar. This will open a window modal dialogue that allows you to drag and drop features from the feature explorer. You can also remove associations from the list using the context menu of a feature.

Figure 2: The Associated Data window with the Associated Features tab opened

Figure 2: The Associated Data window with the window modal window for modifying the list of associated features.


Create Features

Last edited: 10/5/2017 11:51:36 AM

The Create Features window is a document window used to create new features in a specific domain.

The window can be opened from the Ribbon's Content tab, from the context menu of a domain in the Domain Explorer's domain tree, from the context menu of a feature type in the Domain Explorer's context tree, and from the context menu of a feature subtype in the Data Domain Explorer's context tree.

You can open any number of feature creation windows at the same time.

All features created from one instance of the Create Features window will be created in the same domain. When opened from the Ribbon and when no focus domain is set you will first be asked to specify that domain. When opened opened from the Data Domain Explorer, from a node in the Data Domain Context or when opening from the ribbon with a focus domain set the appropriate domain is automatically set.

The window can be operated in two different modes: Simple mode and Expert mode. The simple mode will be sufficient for many uses and will ask the user only for the most important information for creating new features. The expert mode gives you the possibility to define many advance options for the creation of new features. You can switch between simple and expert mode using the Expert mode command button in the window's toolbar.

Features are created according to a feature creation model that you define in this window. In the simplest case the feature creation model is just the specification of a few basic characteristics of the features to be created, however you can also define more complicated creation models in this window that may create multiple features of different feature types and can also specify a platform relation between the newly created features. The feature creation model you define in this window can be persisted as a Feature Creation Template that can be reused later for a faster creation of features.

A feature creation model contains one or more feature creation specifications. Each feature creation specification defines the characteristics of features that will be created from that specification. The feature creation model defines the domain for all features and the platform relation that will be build between the features created from different feature creation specifications.

After you created features from this model (i.e. after you executed the feature creation model) the newly created features will be automatically added to the Feature Selection (if you have the right to list the feature).

Table 1 shows the characteristics that can or must be specified with each feature creation specification.

Characteristic | Description
Feature type | Mandatory. The feature type of the features created from this specification. Only feature types that are available in the selected domain and that are licensed will be available in this list.
Feature name specification | Mandatory. Specification of one or more feature names. Names can be directly specified you can use text templates and you can use a loop mode to create many features at the same time.
Feature subtype | Optional. The feature subtype for the features created from this specification. Only subtypes available in the current domain will be shown.
Data source | Mandatory (Default is Native). The data source for the created features.
Connector type | Mandatory if data source is Connector. If the data source is set to connector the connector type must be specified.
Default sensor | Optional. The sensor that will be set as default sensor for all features created from this specification.
Spatial system type | Optional. The spatial system type the newly created features shall use.
Spatial reference system | Mandatory if a spatial system type was specified. The spatial reference system. Here you can select one of the spatial reference systems that are available in the current domain.
Use relative location | If set defines that the features' spatial location shape and orientation is given relative to the container feature (if any)
Instance specification | Mandatory. Defines the number of features to be created from this specification and the names of these features. Redbex supports two different types of instance specifications. Name list: A simple list of feature names.

Table 1: Characteristics that are defined in a feature creation specification.

Instance specification

Two types of instance specifications are supported: Name list and Iterated. A name list is a simple list of names of features to be created. The names given here are text templates. Table 2 lists the additional text template variables available in this context. The iterated instance specification allows you to specify an iterator variable (start value, step) and a count of features to be created. The name template is again a text template with the variables shown in table 2 but with the additional variable {{index}} that contains the iterator variable value.

Variable | Description
featuretype | Name of the feature type of the features to be created by the current creation specification.
featuresubtype | Name of the feature subtype of the features to be created by the current creation specification.
parentfeaturetype | The feature type of the parent feature if the feature creation specification creates features in a parent platform feature.
parentfeaturesubtype | The feature subtype of the parent feature if the feature creation specification creates features in a parent platform feature.

Table 2: Text template variables additionally available with the instance specification

Figure 1: The Create features window shown in simple mode.

Figure 1: The Create features window shown in advanced mode.


Document Folder Explorer

Last edited: 10/5/2017 11:51:38 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Export Definition

Last edited: 10/5/2017 11:51:38 AM

The Export Definition window is a document window used to create or modify the definition for data exports. For new export definitions the window can be opened directly from the Ribbon's Content by selecting New Export or via the Export Definitions window. For stored export definitions the window can be opened from the Export Definition Window only.

Note that export definitions are always personal i.e. only the user who creates the definition can see and modify the definition.

The window's content is separated into tabs. The General tab and the Settings tab are always shown. The tabs Type specific settings, Extra Type Configuration and Observation Filter are only available if an Export type is chosen on the General tab and if that chosen export type support those additional settings.

The Settings tab shows a property grid that is used for specifying settings common to all types of exports.See chapter export definition for a detailed description of the available settings.

The Type specific settings tab also shows a property grid. The available settings in this property grid depend on the Export type chosen. Please refer to the documentation of the used export type for a description of the available settings.

The Extra Type Configuration tab may be available for some export types and provides other settings the chosen export type provide. See the documentation of the export type for more details.

The Observation filter tab is only available for some export types that deal with observation data. It allows you to limit the observation data exported in various ways.

Figure 1: The Export Definition Window


Export Definitions

Last edited: 10/5/2017 11:51:38 AM

The Export Definitions window is a document window used for accessing and managing export definitions stored by the current user. The window can be opened from the Content tab in the Ribbon.

The Export definitions window shows definitions created by the currently logged on user only.

To create a new export definition choose Add in the Window's toolbar. Existing definitions can be opened by double clicking the list element or by opening the context menu and selecting Edit. The context menu also provides the possibility to Delete an existing export definition and to directly Run an export Definition

Figure 1: The export definitions window.


Feature Explorer

Last edited: 12/13/2017 1:31:38 PM

The Feature Explorer is a tool window used for listing features, it is the main place from where you can access features (including their observations) and from where you can start a multitude of feature-related actions.

You can open the Feature Explorer from the Content & Structure Ribbon tab. The Feature Explorer will be automatically opened on the first start of the Smart Client. Since the Feature Explorer is the main window from which you can access features (including their observations) and many other feature-related functionality we recommend to leave this window open all the time.

The Feature Explorer has three main Panels:

·View Members: shows the result of a view execution (i.e. the view members)

·Selection: Showing the current user's personal selection of features

·Feature Sets: Sets of features that defined by the current user.

Using the drop-down list on the bottom of the window (figure 1: 1) you can manually switch between these Panels. The Smart Client will however automatically change to a specific Panel whenever the user performs an action that influences the data shown in that panel.

Figure 1: Switching between different panels of the feature explorer

The window's toolbar will change according to the selected panel, the Refresh button an the Node visibility button are however always shown. (Figure 1:2, 1:3). The information bar below the toolbar displays information about the displayed features, depending on the panel.

Features tree

Each Panel contains a tree view control that shows all features relating to this panel as root nodes. By expanding a root node you can explore the feature relations of this feature to other features. Which type of relations will be shown depends on the user's definition of node visibility that can be changed by opening the node visibility window from the toolbar (figure 1:3).

The layout of the tree views and the actions you can perform on the features shown there are nearly identical in each Panel.

Each feature displayed in the tree view shows plenty of information that allows you to gather the most important information of the feature quickly. Each feature is shown with the icon of the feature type or the feature subtype (if an icon was defined for that feature's subtype) - see figure 1:2. The icon may have an overlay (a small badge added to the icon) to show specific characteristics of the Feature. Table 1 explains the used overlays.

Figure 2: Display of features in the Feature Explorer

Icon | Notes
 | Feature with calculation data source (black ∑ overlay)
 | Feature with connector data source (blue connector overlay)

Table 1: icon overlays used in the Feature Explorer.

Right to the feature type icon the Feature name is shown (figure 2:4). Names of deleted features will be displayed using light gray text color.

The colored vertical bar left of the feature type icon (figure 2:2) shows the current Approval status of that feature, each approval status corresponds to a color as shown in Table 3.

Color | Description
 | In Progress
 | Ready
 | In Approval
 | Approved
 | Approval denied
 | Approved but erroneous
 | Approval aborted
 | Approval exired

Table 2: Color codes for the approval status of a feature

Right to the feature name (figure 1:5) additional icons are shown for specific features. Table 3 shows the icons that may be shown and their meaning.

Icon | Description
 | Feature is a platform feature
 | Feature is part of a platform feature
 | Observation monitoring is turned off for this feature

Table 3: Additional icons used for describing specific feature characteristics

The tool tip text on each feature (figure 1:6) shows the feature name and other information about the feature.

The tree view allows you to select a single or multiple features, using the context menu you can then perform several actions on the selected features. The context menu will change depending on the selected features. The actions that can be selected from the context menu are nearly identical in each panel of the view browser.

The tree view on each panel can be filtered quickly by using the Filter box.

Opening Features

To open a feature, i.e. to open the Feature Editor window for a the selected feature you can select Open from the context menu of the feature or can just double click the feature in the Feature Explorer. Opening feature from the context menu will only be available if for up to 10 selected features, i.e. you can open 10 features in 10 instances of the Feature Editor at once.

If there is a specialized Feature Editor Window for the feature type of the selected features (e.g. for the document folder feature type) the context menu will include entries to open the feature with those specific windows or with the Feature editor.

When selecting Open from the context menu or when opening the Feature Editor by double clicking a feature the Smart Client will check if a Feature Editor for that specific feature was already opened, and if yes will show that instance of the Feature Editor. However if you intentionally want to open the same feature two times (e.g. for comparing data etc) you can select Open in new instance from the context menu (in this case please also remember that you are working with disconnected data7 ).


%Text%

Navigation: Smart Client > Windows > Content & Structure > Feature Explorer >

View Members Panel

Last edited: 11/8/2017 9:31:52 AM

Whenever you execute a view (usually from the context menu of a view in the View Explorer) the results of the execution (the view members) will be shown in the Feature Explorer window's View members panel. If the Feature Explorer window was not opened at the time when the view was executed the window will be automatically opened.

The information bar shown in this panel (figure 1:1) displays the Name of the view whose members are currently displayed and the total number of features that are member of the executed view.

The view's member features are shown in the central tree view control one feature per line. For performance reasons the View member panel implements paging, i.e. the members of the view are split in pages and only one page is shown at a time in the tree view control of this window. The number of features per page can be adjusted in the Smart Client Settings. You can use the pager control on the bottom of the window to flip through the pages (figure 1:2).

The tree view control will display deleted features if the view whose contents are listed in the Feature Explorer includes deleted features. Deleted features are displayed with light gray font color (figure 1:4)

The features in the tree view are ordered as defined by the view.

Selecting Reload (figure 1:3) from the toolbar will re-execute the view that initially generated this feature listing.

Figure 1: The Feature Explorer window with View Members panel.


%Text%

Navigation: Smart Client > Windows > Content & Structure > Feature Explorer >

Feature Selection Panel

Last edited: 10/5/2017 11:51:38 AM

This panel of the Feature Explorer window lists all features that are in the user's current selection. The Feature Selection is a personal and temporary (will not be persisted when you close the Smart Client) set of features that is especially useful if you want to perform some common action on a set of features that are not members of a specific view.

You activate this panel of the Feature Explorer window by selecting Feature Selection Panel on the bottom of the Feature Explorer (figure 1:1).

The panels information bar shows the number of features in the selection (figure 1:2). Selecting Reload (figure 1:3) from the toolbar will reload information for all features in the selection.

Figure 1: The Feature Explorer with the Current Selection panel

Setting the Adding mode

The Feature Selection can be in one of two adding modes, which can be switched from the window's toolbar (figure 1:4).

1.Append: Features that are sent to the Feature Selection are appended to the set of features already in the Feature Selection.

2.Replace: Whenever new features are sent to the Feature Selection the Feature Selection is cleared first and then the new features are added.

Adding and Removing features

Features can be manually added to the Feature Selection from the View Members panel of the Feature Explorer, but also from many other places in the Smart Client e.g. Map View or Charts.

Some actions will automatically add the resulting features to the Feature Selection:

·Creation of new features: Newly created features are sent to the Feature Selection

·Searching for features: results of a search are sent to the Feature Selection

Whenever features are added to the Feature Selection the Feature Selection panel in the Feature Explorer will be activated.

To remove specific features from the Feature Selection you select the features you want to remove and choose Remove from list from the context menu (figure 2:1) or press Del.

Note that the Smart Client limits the number of feature in the feature selection to 100.

Creating a named set from the Feature Selection

If you want to persist the features in the Feature Selection as a Feature Set you can create a Feature Set out of the Feature Selection by selecting Create set from selection in the toolbar (figure 1:5).

Using the context menu of one or more selected feature in the Feature Selection Panel you can also choose to add the selected features to a specific (previously created) Feature Set (figure 2:2)

Figure 2: The context menu for features in the Feature Selection panel.


%Text%

Navigation: Smart Client > Windows > Content & Structure > Feature Explorer >

Feature Sets Panel

Last edited: 10/5/2017 11:51:38 AM

The Feature Sets panel shows Feature Sets created by the current user. Feature sets are named and persisted sets of features that are especially useful if the user wants to create sets of features for common actions that are not members of a single view.

The Feature Sets Panel can be activated by selecting the Feature-Sets button on the bottom of the window (figure 1:1)

The Feature Sets panel is used to show or modify any of the current user's feature sets. The Drop down list in the Toolbar (figure 1:2) can be used to switch between the Feature-Sets of the current user. The tree view will always show the set members of the Feature-Set selected in the toolbar. Selecting Reload (figure 1:3) from the toolbar will reload information for all features in the currently shown feature set.

Select Edit from the Toolbar to change name or description of the current feature set. Select Delete from the toolbar to delete the current feature set. Note this only deletes the Feature-Set but not the features!

Figure 1: The Feature Explorer with the Feature Sets panel

Creating Feature Sets

Feature sets can be created from this panel by selecting Add from the toolbar. Alternatively feature sets can be created (and immediately filled) from the Current selection panel.

When creating a new feature set a modal window will ask for a Name and optionally for a description of that feature set (figure 2)

Figure 2: This modal window is shown when a new Feature Set shall be created.

Adding and removing members

Features can be added to feature sets from either the Current Selection panel or the view member Panel. Note that in both cases the Set has to be created first.

To remove features from a Feature Set select those features in the list view and choose Remove from list from the context menu.

Adding features to Current Selection

Features in a Feature set can be added to the Current Selection by selecting those features in the list and then choosing Add to selection from the context menu.


Feature Configurations

Last edited: 10/5/2017 11:51:36 AM

The Feature Configurations window is a document window used to display create and modify feature configurations in a specific context. The window can be opened from the Data Domain explorer' context area in the context menu of a feature type or a feature subtype, or from the Feature Explorer in the context menu of a feature.

The place from which the window is opened defines the context for the window. This context is shown in the info bar of the window. The window will list all feature configurations that are available in this context and in contexts superior to it. When you create a feature configuration from this feature it will be always created with the same context as the current window' context.

Every element in the list of this window will show the context in which the element is defined and will show if the configuration has a visual appearance set and if the configuration has at least one report template set.

Figure 1: The feature configurations window


%Text%

Navigation: Smart Client > Windows > Content & Structure >

Feature Directives

Last edited: 11/8/2017 10:04:52 AM

The Feature newly created Directives window is a document window used to show and manage Feature Directives defined for a specific feature. The Window can be opened from the context menu of a feature in the Feature Explorer.

Multiple instances of this window can be opened at the same time but only one window can be opened for one specific feature.

The window mainly consists of the toolbar and tabs, one tab for each type of Feature Directive available: Observation monitoring Definitions, Observation Plans and Approval Template Assignments. Each of these tabs shows a list of configurations that are applicable to feature for which this window was opened. I.e. these lists also contain configurations that were associated for parent features but apply to the current feature due to the Feature Directive Applicability.

Selecting the Add menu button you can create new Feature Directives associated with the Feature for which the window was opened. Each feature directive will be opened in a separate document window.

Figure 1: The Feature directives window with the Observation monitoring Definitions tab opened

Figure 2: The Feature directives window with the Observation Plans Tab opened


Observation monitoring Definitions

Last edited: 12/14/2017 8:14:54 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


%Text%

Navigation: Smart Client > Windows > Content & Structure > Feature Directives >

Observation Plans

Last edited: 10/5/2017 11:51:30 AM

Observation Plans are configured as Feature Directive. The Observation Plans tab in the Feature Directives window shows the Observation Plans directly created for the feature for which the Feature Directives window was opened or inherited by some parent feature.

Each element in the list shows one observation pan.

Double clicking an element in the list or selecting Edit from the context menu will bring up the Observation Plan window. An existing Observation Plan can be deleted by selecting Delete form the context menu of a list element or by hitting the Del key.

Figure 2: The Feature directives window with the Observation Plans Tab opened


Approval Template Assignments

Last edited: 12/14/2017 8:15:54 AM

Which approval template is used for a specific feature or the observations of a specific feature is defined by approval template assignments. The Approval Template Assignments tab in the Feature Directives window shows the Approval Template Assignments directly created for the feature for which the Feature Directives window was opened or inherited by some parent feature.

Each element in the list shows one approval template assignment. The Feature field shows which approval template will be started for features and the Observation field shows which approval template will be started for observations.

Double clicking an element in the list or selecting Edit from the context menu will bring up the Approval Template Assignment window. An existing assignment can be deleted by selecting Delete form the context menu of a list element or by hitting the Del key.

Figure 1: The Feature Directives window with the Approval Template Assignments tab opened


Feature Editor

Last edited: 10/5/2017 11:51:38 AM

The feature editor a document window that is the main place for accessing and modifying data of a feature i.e. data of the feature itself and data of all of its observations. The feature editor automatically adapts to the type of the feature it displays or to be more precise automatically adapts to the property structures used in the type specific feature data and the type specific observation data.

You can open any number of feature editors but the same feature can only be opened once. If you try to open the same feature again the feature editor of that already opened feature will be shown.

The title bar of the window always shows the name of the feature and the icon of the feature's type.

The toolbar (figure 1:1) provides buttons for operations on the feature or on observations. The toolbar dynamically changes according to the selected tab. (figure 1:3). These tabs give access to different data of a feature (feature 1:3). Which tabs are shown depends on the feature type class and depends on whether the feature is a calculated feature or not. See table 1 for a short description of each tab. Following chapters explain each tab in more details.

Beneath the toolbar (the info bar displays information about the spatial system used with this feature or its observation (figure 1:2). This information is necessary for the right interpretation of spatial data and other data referring to the spatial system within the feature or the feature's observations

Tab | Use
Base data | Non modifiable Base data of the feature including ID, Creation data, Type, Subtype and domain. If the feature-types spatial support is on feature the spatial data is also shown on this page.
Type specific data | While this tab is always visible the tab has no content if the feature-type does not define a property structure for type specific feature data.
Observations | While this tab is always visible the tab has no content if the feature-type does not define a property structure for type specific observation data, and the feature type's spatial support is not on observations.
Relations | Only shown if the feature is a container feature. If so this tab can be used to view or create relations of the container feature to other features.
Calculation settings | Only shown for calculated feature. This tab is used for specifying some general calculation settings.
Calculation algorithm | Only shown for calculated feature. This tab allows to define or edit the calculation algorithm.
Connector settings | Only shown for feature with data source Connector. On this tab all the settings for the connection to the data source are defined.

Table 1: The main tabs found in the feature editor.

Figure 1: Overview of the Feature editor.


Base data tab

Last edited: 10/5/2017 11:51:38 AM

On the base data tab the feature editor shows controls for displaying an editing feature identification data, base data and spatial data. Depending on the spatial support of the feature type and depending on the spatial system selected when the feature was created this tab shows also the control for spatial data.

Figure 1 shows the feature editor with the base data tab opened (in this case for a feature of type Inclinometer). Some base data is write protected ant therefore the controls are shown read only.

ID | Id of the feature. This is a numeric Id assigned by the Application Server that uniquely identifies the Feature on the Application Server
Created on | This is date when the feature was created, i.e. when the feature was first saved on the Application Server
Feature type | The feature type of the feature
Feature subtype | The feature subtype of the feature. The subtype of the feature. While this control is read only the subtype of a feature can be changed from the Feature Explorer.
Domain | The domain this feature belongs to
Name | The name of the feature
Description | A description of the feature.
Default senor | This is the sensor that will be automatically used for newly created observations. Changing this has no effect on already existing observations. The used sensor can also be set manually fore each observation.

Table 1: Base data shown on this tab in the feature editor

Figure 1: The Feature editor. Here shown with the Base data tab.


Type specific data tab

Last edited: 10/5/2017 11:51:38 AM

This tab shows the property structure instance for the type specific data of the feature. If the feature's type does not specify a property structure for type specific feature data this tab will be empty (as shown in figure 1), else the property structure will be automatically shown as hierarchical form.

Figure 1: The Type specific data tab if the feature's type does not define a property structure for type specific feature data


Specifying spatial data

Last edited: 10/5/2017 11:51:38 AM

In the feature editor you can modify LSO of a feature or of observations. Depending on the used spatial system the window shows different spatial data controls for specifying the LSO. If the feature types spatial support is on feature the controls for specifying the LSO are shown on the base data tab, if the spatial support is on observation the controls are shown on the observations tab.

The spatial controls can be collapsed and expanded to save screen space (figure 1:1). To reset the values to null you can use the Eraser button in the right upper edge of the spatial data control (figure 1:2).

When the feature's spatial data is given in a projected or geographic coordinate system the data is presented as shown in figure 1 or figure 2. You can switch between these two presentations using the option buttons shown in figure 1:3. Selecting Point here will show the control as pictured in Figure 1:1 Here you can enter Easting (X), Northing (Y) and Elevation. The unit for Easting and Northing is the linear unit defined in the coordinate system. The unit of the elevation is the linear unit of the vertical coordinate system used by the coordinate system.

Selecting Geometry will show the control as pictured in figure 1:2. Here you can specify the geometry using WKT strings. For point geometries it is usually easier to just enter Easting and Northing however polygons, line-strings etc. can only be specified using WKT. Note that usually you will not manually enter WKT - you can use the shape definition window to graphically define the LSO of a feature or observation.

When changing the WKT string the Smart client checks if the string entered is a valid WKT if not a message will be written to the output window and the WKT will be rest to the previous value.

If the spatial system used by the feature is an axis reference system the spatial control pictured in figure 3 is shown. Start offset and End offset specify the interval on the axis reference system the LCS boxes specify the offset from the axis measured in the local coordinate system.

Figure 1: The control for specifying LSO's with a point geometry in a projected or geographic coordinate system

Figure 2: The control for specifying LSOs with a geometry given as WKT in a projected or geographic coordinate system

Figure 3: The control for specifying LSO's in an Axis Reference system.


Copying observations

Last edited: 10/5/2017 11:51:38 AM

In order to facilitate the input a new observation can from the copy of an existing observation.

In this case the new observation will be a nearly exact (limitations see below) copy of the original observation. This includes, base data, type specific data, sensor configuration and spatial data of the observation.

The identification data of the newly created observation is of course changed. The sampling timestamp is set to the date and time of the creation and the observation Id (once the observation is saved) will be the If assigned by the Application Server.

Property values of properties of type binary and referenced image will not be copied to the new feature. Also Comments and Attachments of the original observation will not be copied.

To create an observation from existing, follow these steps:

·Select an observation on the observation tab in feature editor. This can be either an existing or a newly created observation. If multiple observations are selected, copy is created from the one that was selected first.

·Click "Create observation from existing" button in the toolbar. New observation will be created and added to the new observations pane

The copy is generated based on the current data of the original observation, i.e. changes to the original observation that are not yet saved to the Application Server will still be copied to the new observation.


Property structure display

Last edited: 10/5/2017 11:51:38 AM

The feature editor displays property structures for type specific feature data and type specific observation data (depending on the feature's type). Property structures can be displayed in different ways: Hierarchical list, Hierarchical form, Tabular, or customized. The feature's type specific data will always display as hierarchical list, for the type specific data of the observation all display types can be used.


Feature privilege

Last edited: 10/5/2017 11:51:38 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Feature Set

Last edited: 10/5/2017 11:51:38 AM

The Feature Set window is a very simple document window that can be used to rename and describe feature sets. The window can be opened from the Feature Explorer's Feature Set panel (figure 2:2)

Figure 1: The feature Set window

Figure 2: Opening the feature set window


General Feature configuration

Last edited: 10/5/2017 11:51:38 AM

The Feature Configuration window is a document window used to display and modify feature configurations. The window is opened from the Feature Configurations window.

In the Visual appearance area you can set the properties for the visual appearance of feature in the context. The system will use the first match approach to determine the visual appearance settings it shall actually use for a specific feature.

The Report templates area can be used to link existing report templates to features in this context. To assign a report template to all features in the context drag a report template from the Data Domain Explorer to the list. The system will use a match all approach and will union all assigned reports.

Figure 1: The Feature Configuration window


Import Definition

Last edited: 12/13/2017 7:03:46 AM

The Import Definition window is a document window used to display and modify the properties of an import definition. The window is used to display and modify stored import definitions as well as import definitions that are created and executed but never persisted as stored import definition (on-the-fly import definitions).

This window can be opened from the Domain Explorer window or from the Content & Structure Ribbon tab.

The window is always opened for a specific import type that defines the type of data source (e.g. a file or a database) as well as the internal data format that is expected in this data source. The import type that the window was opened for is described in the information bar (figure 1:1)

The window shows multiple tabs (figure 1:2). On the General settings tab you can define settings which are available for all import types. On the Format settings tab you can define settings that are specific to the current import type.

On the Sources tab you define which data sources will be processed by the import when this import definition is executed i.e. where the data will be loaded from. To add new sources for files select the Add button in the window's toolbar, you can then choose from several different import source types. Note that if you specify Files from depot import source type this source specification will not be be stored when the import definition is persisted as stored import definition, all other source types will be persisted. You can add any umber of sources for one import definition. Selecting one element in the list of import sources will show the specific settings available for that import source type in a property grid (See figure 2). For a description of the settings for each source type see chapter Import source types.

On the General tab you can define settings that are used for saving the import definition as stored import definition to the domain context. To actually save the import definition select Save in the toolbar. You may also create a copy of an already saved import definition by selecting Save a copy from the window's toolbar.

Selecting Execute in the toolbar will execute the import definition. Import definitions are executed on the Application Server as jobs. The results of the execution can then be seen in the import session log.

Figure 1: The import definition window

Figure 2: The sources tab of the import definition window


Import Sessions

Last edited: 12/13/2017 7:03:54 AM

The Import Sessions window is a document window used to list and manage the import sessions instantiated for either one specific stored import definition or for all on-the-fly import definitions.

The window consists of two main areas. In the upper area a grid shows the import sessions that were instantiated for the import definition from which this window was opened or all the on-the-fly import sessions the accessing user instantiated.

The lower area shows details about the currently selected import session in the grid. The Imported files list view shows all files that were processed by this import sessions. If the import definition advised the Application Server to store the source files you can download the source file by selecting Download from the context menu of an imported file.

The Affected features list view shows all features that were created by this import session. You can open the feature from the context menu of each listed feature.

Figure 1: The import sessions window.


My Approvals

Last edited: 10/5/2017 11:51:40 AM

The My Approvals window is a tool window that shows pending or historical approval obligations assigned to the currently logged on user. It is the place in the Smart Client where you can actually approve or deny approval. You can open this tool window from the Ribbon menus Content tab.

The window can either show only approval obligations that have not been fulfilled or approval obligations that were fulfilled in the past. Use the Historic / Pending toolbar button to switch between these two display options (figure 1:1).

The list in this window shows one entry for each approval obligation of the current user. Each list element shows the Feature and the observations this approval obligation is for and it shows the current status of the obligation. The icon on the left side of the entry shows if the obligation is for a feature or for observations of a feature

Using the context menu of an element in the list you can Approve or Deny. Using open feature (or open observation in case of observation approval) you can open up the Feature editor to review the data before approving or denying.

Figure 1: The My Obligations window


Observation Plan Violations

Last edited: 10/5/2017 11:51:40 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Observation Spying Definition

Navigation: Smart Client > Windows > Content & Structure >

Observation monitoring Definition

Last edited: 10/5/2017 11:51:40 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Shape definition

Last edited: 10/5/2017 11:51:40 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Stored Import Definitions

Last edited: 12/13/2017 7:02:48 AM

The Stored Import Definitions window is a document window used to list and manage the stored import definitions of the currently accessing user. This window can be opened from Data Domain Explorer window.

The stored import definitions for the domain from which the window was opened and and for all of its parent domains are displayed in a list view. Each list element shows the name of the import definition, the description and the domain which this stored import definition is associated with.

The context menu for the elements in the list view gives access to actions relating that element.

To create a new (stored) import definition click Add in the toolbar. Note that you can also create a new on-the-fly import definition that way by just not storing the new import definition. To edit an already stored import definition select Edit from the context menu.

You can show the import sessions that were instantiated from a specific stored import definitions by selecting Import sessions from the context menu of the import definition. To immediately run a stored import definition select Run from the context menu.

To delete a stored import definition select Delete from the context menu. Note that if you have defined a job that executes this stored definition this job will not be automatically deleted. However the execution of that job will fail. Therefore you should also delete any job definition that uses this import definition.

Figure 1: The Stored Import Definitions window.


Validation Browser

Last edited: 10/5/2017 11:51:40 AM

This tool window allows monitoring and managing active and finished validation runs that were initiated by the currently logged in user. You can start this window from the Ribbon's Common tab.

Validation runs are created and started from the validation subjects, e.g. validation on a feature is started from the Feature Explorer. As soon as a validation run has been created it will show up in this window (when data for this window is reloaded). Alternatively validation runs can be started by stored job definitions.

The list of validation runs shown in the List is sorted descending by start date. I.e. the latest validation run is shown on top. The window can be used to access all validation runs initiated by the current user. Validation runs initiated by other users cannot be shown.

Each list element shows when the validation was started and when it finished, if the validation is still running the finished date will be empty. The Status field shows the validation run status.

Via the context menu available for elements in the List you can open the Validation Results window for selected validation runs, and delete selected validation runs. If you delete a validation run that is still being processed the job on the Application Server that is performing the validation will be canceled too.

Figure 1: The Validation Browser window


View

Last edited: 11/8/2017 10:04:52 AM

The View window is a document window used to create and modify views. The window can be opened from the context menu of a view in the View Explorer window.

On the General tab the Name box shows the name of the view. Each view must have a (non empty) name, maximum length for a view name is 200 characters. The system does not check a view name for uniqueness, but we suggest you choose unique names at least within one hierarchy level.

The description box can be used to describe the view. This description is also shown as tool tip on the view in the View Explorer window.

The Sequence number can be used to define the order in which views will be displayed in the View Explorer window. New views will by default have a sequence number of zero. You can use any integer (negative or positive). In one hierarchy level views with lower sequence number will be displayed before views with a higher sequence number. In the View Explorer window views of one hierarchy level will be sorted first by sequence number and then by name.

The Personal view switch is enabled only on creation of a new view. If you modify an already existing view this check box will be read only. If selected, the view is a personal view and therefore only visible to the current user. Root views cannot be marked as personal views.

The Non-listing view check box defines if the view or not see chapter Non listing views for more details.

You can assign a color to a view, this color is used by the Smart Client (and probably other clients) to display the view.

On the View Filter tab you define the actual filter criteria that defines the members of the view. This tab consists of two main areas. The Expression tree area shows the tree-like structure of the view filter expression, the Details area shows details about the combination node or filter term currently selected in the Expression tree.

In the Expression tree combination nodes are shown with a chain link symbol (Figure 1:1) and the logical operator they represent; possible logical operators are: AND, OR, NOT AND, NOT OR . If you select a combination node in the Expression tree you can configure the logical operator in the Details area. The context menu of a combination node allows you to add subordinate combination nodes or filter terms. All combination nodes except the root node can be deleted. Deleting a combination node will also delete all its subordinate combination nodes and filter terms.

Filter terms are shown with a blue ball symbol and a textual representation of the filter term (Figure 1:2). The textual representation does not always describe all settings of the term, it is just a hint to quickly assess the term. If you select a filter term in the Expression tree you can configure the properties of this filter term in the Details area. Every filter node type has it own properties described in chapter View filter terms.

The context menu of a filter term node allows you to delete that filter term node.

The check box left of each term or combination node deactivates the term or combination node. This can be useful when designing your view terms. Note that a view with no term node or with no active term node will always return in an empty view member set.

Note that the Application Server will always check the supplied expression tree on saving. If the expression tree does not actually filter for any data the Application Server will modify the expression tree by adding a Contradiction term (if view is a root view) or a Tautology term (if view is a subordinate view), or by enabling combination nodes.

The Test filter expression button in the toolbar allows you to test the view filter expression. You have to save any changes the view to make this button enabled. Selecting Test will execute the view with the (modified) filter definition and show the results in the Feature Explorer window.

Figure 1: Example of a view filter as displayed in the Expression tree.

On the View Order tab you define how the member features of the view will be ordered when the view gets executed. See chapter View ordering for a description of available view orderings.

The Domains tab allows you to associate a view with one or more domains. To associate the view with all domains use the respective Switch. To associate a view only with specific domains drag those domains to the list of domains. Note that the association is not inherited by subordinate domains. or subordinate views.

The Workspaces tab allows you to expose the current view as one or more workspaces. If this tab is active the toolbar shows the Add new workspace drop-down button. From this drop-down button you can select a workspace type and create a new workspace of that type. To edit an existing workspace select the workspace in the list view and select Edit from the context menu of the list entry or double click a workspace. Creating and modifying a workspace will bring up the Workspace window. To delete a workspace select delete from the context menu of that workspace or press Del.

Figure 2: The View Editor window with the General tab opened

Figure 3: The View Editor window with the Filter tab opened

Figure 4: The View Editor window with the View Order tab opened

Figure 5: The View Editor window with the Domains tab opened

Figure 6: The View Editor window with the Workspaces tab opened


View Explorer

Last edited: 11/8/2017 10:04:52 AM

The View Explorer is a tool window that displays the view structure. The View Explorer can be started from the Common Ribbon tab. The View Explorer will display all views in the view structure for which you have the appropriate permission.

The views displayed in the tree are loaded on demand, i.e. whenever you expand view to see its subordinate views the data will be loaded from the Application Server. Only the root views will be loaded immediately when the window is opened.

The views in the Vie Explorer are sorted by Sequence number and then by view name. The view name is shown in the color defined by the view (default is black).

The icons used in the tree view show specific characteristics of the view, see table 1 for a summary.

Characteristic | Icon | Notes
Public view |  | A yellow folder icon is used for public views
Private view |  | A blue folder icon is used for personal views
Hidden view |  | If a view is hidden for the current user a hidden badge will be overlayed.

Table 1: Characteristics of views expressed as icons

In the View Explorer you can search for views by view name. The search area beneath the window's tool bar (figure 1:1) can be used to quickly search for a view and highlight the found views. In the search area you can enter a the search pattern. If the search pattern includes one or more wildcard characters (see table 1) it will search for all views that match the search pattern. If none of these wildcard characters are present the Application Server will search for all view names starting with the search pattern string.

After changing the search pattern press Enter to search for the first match press Enter repeatedly to search for the next matches.

Wildcard character | Description | Example
% | Any string of zero or more characters. | %Name% matches AB Name as well as AB Name CD as well as Name1 %Name% does not math AB Nam CD %Name does not math Name CD
_ | Any single character. | Feature _ matches Feature 1 as well as feature A
[] | Any single character within the specified range ([a-f]) or set ([abcdef]). | Feature [12345] matches Feature 1, Feature 3 but not Feature 9
[^] | Any single character not within the specified range ([^a-f]) or set ([^abcdef]). | Feature [^A-M] matches Feature M to Feature Z but not Feature A to Feature M

Table 1: Wildcard characters that can be used within the search pattern

Executing a view

To execute a view choose Execute from the view's context menu our double click the view. The filter expression that is associated with the view will then be executed on the Application Server and the resulting features (view members) will be returned. The view members will be displayed in the Feature Explorer window. If the Feature Explorer is not opened at the time the view was executed it will automatically show the resulting features once it is opened. The Execute context menu item is not available if the view is a non listing view.

You can also choose to Execute to selection to execute the view and place the result of the execution in the Feature Selection.

If you are working repeatedly with specific views you can make those views your personal favorites, they will then appear in the favorites window and you can quickly execute this view from there. To make a view a favorite open the context menu for that view and select Add to favorites. Deleting a favorite is done from the Favorites window.

Creating, modifying and deleting views

To edit a specific view select Edit from the view's context menu, this will open up the View window for the selected view.

To create a new root view select the Create root view button from the toolbar, this will open up a View window where you provide the details of the new view. You need the System permission All permissions on root views (1) to create root views

To create a subordinate view of a specific view select Create subordinate view from the context menu of the parent view. This will open up a View window where you provide the details of the new view. You need the view permission Modify view (0) on the parent view to create subordinate views.

You can copy the definition of a specific view by selecting the source view and then selecting Copy from the context menu. Afterward you can create a copy by either pasting the definition as a new subordinate view of a selected view or by pasting the definition as new root view. Of course pasting only works if you have the appropriate permission.

It is not possible to change the parent view of a view. If you want to move a view beneath another parent view you can just copy the view definition. Note that copying a view does not copy the privileges defined for that view.

Deleting a view can also be triggered from the context menu. Note that deleting a view will automatically delete all subordinate views of that view; it will not delete any view members.

Hiding views

To hide or show a view select the Hidden for all users ore Hidden for current user toggle menu entry from the views context menu (figure 2). Hidden views will only be shown in the View explorer if the Show hidden views toggle button (figure 2:1) is selected in the window's toolbar

Domain focus

The view Explorer will by default react to the Data Domain Focus, i.e. the views shown in the View Explorer are filtered according to the current Data Domain Focus. You can disable this filtering by selecting Ignore Data Domain Focus on the toolbar (figure 1:2).

Figure 1: The view explorer

Figure 2: The View Explorer window showing hidden views.


Domain & Context

Last edited: 10/5/2017 11:51:12 AM

This chapter describes Smart Client windows that are used to manage domains and other data that is directly connected to domains.


Alias Scheme

Last edited: 11/8/2017 10:04:52 AM

The Alias scheme window is a document window used to display and modify a single alias scheme. The window can be opened from the context menu of a domain in the Domain explorer window.

On the General tab you define general properties of the alias scheme (see figure 1). Note that an alias scheme always belongs to a specific domain. The association with this domain cannot be changed.

The Alias names tab is where you define alias names for features within this alias scheme. The alias names are defined within a grid. To add features for which you want to define alias names drag and drop those features from the Feature Explorer window to the grid. Afterwards select each grid row and define an alias name by first pressing F2 and then typing in the new alias name. You can also use F2 to change the name of an existing alias.

Deleting an alias name of a feature can be accomplished by selecting the row with the specific feature in the grid and then choose delete from the context menu.

Figure 1: The alias scheme window


Attachment tags

Last edited: 10/5/2017 11:51:36 AM

The Attachment tags window is a document window used to display and modify the names of attachment tags for a specific feature type in a specific domain. The window can be opened from the context menu of an Attachment tags node in the Domain explorer's context area (see figure 1).

The Attachment tags window shows a text box for each of the 10 predefined tags. Using this text boxes you can rename each tag. Remember that the renaming only applies to feature type and domain (and subordinate domains) shown in the info bar.

The colors of the attachment tags are predefined and cannot be chanted by the user.

Figure 1: Opening the Attachment tags window from the Data Domain Explorer.

Figure 2: The Attachment Tags window


Available Feature Types

Last edited: 10/5/2017 11:51:38 AM

The Feature type availability window is a document window used to display and modify the feature types that are available within (and underneath) a specific domain, i.e. which feature types can be used when creating new features within that domain.

This window can be opened from the context menu of a domain in the Data Domain Explorer. To modify the availability of feature types you need the domain permission Hide feature types (6).

Note that this window only shows the settings for the availability of feature types in the domain for which the window was opened. A feature type is only effectively available within a specific domain if it is available in all the domains of the specific domains path.

The list view of this window contains all feature types installed. Each feature type is shown with its name and description. The checkbox on the left side of each list view element is selected if the feature type is available.

Figure 1: The Feature Type Availability window


Navigation: Smart Client > Windows > Domain & Context >

Axis

Last edited: 10/5/2017 11:51:04 AM


Axes

Last edited: 10/5/2017 11:51:36 AM

The Axes document window lists the Axes associated with a specific domain, i.e. all axes that are directly assigned to this domain. The window can be opened from the context menu of a domain in the Data Domain Explorer. You need the domain permission Read (0) on the domain to list its axes.

The list view on this window lists name and description of each axis that is member of the domain for which the window was opened. From the context menu of an axis you can select Edit to open the axis in an Axis window.

Select Delete in the context menu of an axis to delete that axis. Note that deleting an axis will fail if the axis has an axis reference system that is used as spatial reference system by some feature.

To open the list of axis reference systems defined for an axis select Axis reference systems from the axis' context menu. This will open the Axis Reference Systems window.

To create a new axis select Add from the window's toolbar. This will bring up an Axis window where you can specify the properties of the new axis.

Figre 1: The Axes window


Axis

Last edited: 10/5/2017 11:51:36 AM

The Axis document window is used to display and modify a specific axis. The window can be opened from the context menu of an axis in the Axes window or from the context menu of an axis displayed in the context panel of the domain window in the Context tree of the Domain Explorer.

You need the domain permission Read (0) on the domain the axis belongs to to open the axis window for this axis. To modify an axis you need the domain permission Manage axes (10) on the domain the axis belongs to.

The geometrical shape of an axis is defined by a series of axis points. Axis points cannot be keyed in directly but are imported from a text file. Selecting Import axis points from file from the windows toolbar brings up a windows modal form that allows you to select a source file from your file depot. Select OK to import the data. A summary of the import will be shown in the Output Window. See chapter Axis points import file format for a description of the file format.

On the General tab of the axis window you can define basic properties of an axis. The ID is the internal (Redbex) ID of the axis The axis Name is mandatory, it is recommended to use axis names that are unique across all domains. If you have numerous axes defined it might be helpful to order the axes using the Path.

Specification of the Coordinate system is mandatory. The setting defines on which coordinate system the axis definition is based, i.e. in which coordinate system the axis points are expressed. Note that changing the axis coordinate system is possible for existing axis but it will give the already defined axis points a different real world position.

The First axis point sloped offset and First axis point horizontal offset boxes are used if the geometrical definition of the axis describes only a part of the axis. The unit for these numerical values is the unit for length measurement in the underlying projected coordinate system.

The Simplification tolerance value is also expressed in the length measurement units of the underlying coordinate system. For more information about axis simplification see chapter Axis simplification. A simplification tolerance lower than zero or will disable simplification, a simplification tolerance equal to zero will only simplify exactly straight parts of the axis.

The Summary tab shows a simple graphical representation of the axis, i.e. a 3D poly-line connecting all axis points. Below the visualization a summary of the axis geometry is displayed. Table 1 explains the data shown in this summary.

Datum | Explanation
Original axis point count | The number of axis points stored for this axis
Reduced axis point count | The number of points used in the simplified axis. If Simplification tolerance is set to zero this will always be the same as the original axis point count.
Horizontal axis length | The length of the geometrically defined axis (without the offset specified for the first axis point) projected to the XY plane, given in the length measurement unit of the underlying coordinate system.
Sloped axis length | The length of the geometrically defined axis (without the offset specified for the first point) given in the length measurement unit of the underlying coordinate system.
First axis point | X, Y and Z Coordinates of the first geometrically defined axis point, given in the length measurement unit of the underlying coordinate system.
Last axis point | X, Y and Z Coordinates of the last geometrically defined axis point, given in the length measurement unit of the underlying coordinate system.

Table 1: Data shown in the axis summary.

Figure 1: The General tab of the axis window

Figure 2: The window modal dialogue to import axis points


Axis Reference System

Last edited: 10/5/2017 11:51:36 AM

The Axis Reference System document window is used to display and modify a specific axis reference system. The window can be opened from the context menu of an axis reference system in the Axes Reference Systems window or directly from the domain context area in the Data Domain Explorer.

You need the domain permission Read (0) on the domain the axis reference system belongs to, to open the Axis Reference System window for this axis reference system. To modify an axis reference system you need the domain permission Manage axes (10) on the domain the axis reference system belongs to.

The window show the properties of an axis reference system for a detailed explanation of all settings see chapter Axis reference system

Figure 1: The Axis Reference System window.

Figure 2: Cross section assignment in the Axis Reference System window.


Axis Reference Systems

Last edited: 10/5/2017 11:51:36 AM

The Axes Reference Systems document window lists the Axes reference systems for a specific axis. The window can be opened from the context menu of an axis in the Axes window, You need the domain permission Read (0) on the domain in which the axis is defined to display axis reference systems.

The list view on this window lists name and description of each axis reference system of the axis for which the window was opened. From the context menu of an axis reference system you can select Edit to open the axis reference system in the Axis Reference System window.

Select Delete in the context menu of an axis reference system to delete that axis reference system. Note that deleting an axis reference system will fail if it is used as spatial reference system by some feature.

To create a new axis reference system Add from the window's toolbar. This will bring up an Axis Reference System window where you can specify the properties of the new axis reference system.

Figure 1: The Axis Reference Systems window.


Classification Elements

Last edited: 10/5/2017 11:51:36 AM

The Classification elements document window is used to display and modify a the elements of a specific classification. The window can be opened from the context menu of an classification in the Classifications window.

You need the domain permission Read (0) on the domain the axis belongs to to display the classification elements of a specific classification. To modify the classification elements you need the domain permission Modify Classifications (13) on the domain the axis belongs to and the feature type permission Modify classifications (2) on at least one feature type the classification type is associated with.

On the left side of the window list view shows all classification elements for the current classification, Select an element in the list view to show the details of that element on the right side.

To add a new classification element select Add from the window's tool bar.

Figure 1: Classification Elements window


Classifications

Last edited: 10/5/2017 11:51:36 AM

The Classifications document window lists the Classifications associated with of specific classification type that are associated with a specific domain. The window can be opened from the Data Domain Explorer in the Data Domain Context area. Under Classifications types select the classification type you want to list classifications for and then select Classifications from the context menu of the classification type.

You need the domain permission Read (0) on the domain to list its classifications.

The info bar on top of the form Shows the context for which the window shows classifications (figure 1:1). The context is the classification type and the domain.

The list view on this window lists name and description of each classification that is member of the domain for which the window was opened, i.e. classifications associated with that domain or any of its parent domains. If a classification is marked as the default classification in the current context a special icon is shown for that list element (figure 1:2).

Select Classification elements from the context menu of a classification in the list view to bring up the Classification Elements window for displaying or modifying the elements of the selected classification. To modify the classification itself select Edit from the context menu. This will open a window modal dialogue (figure 2) that allows you to change Name and Description of the classification.

To set a classification as the default classification in the current context of the window select Set as default from the context menu of that classification.

To create a new classification select Add from the window's tool bar. This will open a window modal dialogue (figure 3) for specifying a name and a description of the classification to be created.

Figure 1: The Classifications window

Figure 2: The Classifications window with the window modal dialogue for modifying a classification

Figure 3: The Classifications window with the window modal dialogue for creating a new classification


Create Data Domain

Last edited: 10/5/2017 11:51:36 AM

The Create Data Domain window is a modal window used to create a domain as subordinate domain of another domain. The window can be opened from the context menu of the parent domain in the Data Domain Explorer.

The name of the domain that you type in the Name box must be unique among all domains with the same parent domain. The Description is optional.

If Break permission propagation is selected the permissions of the newly created domain will not be propagated to subordinate domains.

Figure 1: The Create domain window.


Domain

Last edited: 11/8/2017 9:27:28 AM

The Domain window is a document window used to display and modify the properties of a domain. The window can be opened from the Edit menu item in the context menu of a domain in the Data Domain Explorer.

The Parent domain box displays the parent of the domain of the currently open domain. The parent domain cannot be changed.

The Break permission propagation checkbox defines if permissions defined for this domain are inherited by subordinate domains. See chapter Domain privileges for more details.

Figure 1: The Data Domain window


Domain Explorer

Last edited: 10/5/2017 11:51:36 AM

The Domain Explorer window is a tool window that shows the defined domains in a tree structure and provides access to data bound to domains. You can open this window from the Ribbon's Content & Structure tab.

The window consists of two main areas the Domain tree (figure 1:1) and the Domain context tree (figure 1:2). The domain tree shows the domain structure you created and provides access to various domain specific actions via the context menu on the domain nodes. The Domain context tree provides a structure that displays objects are defined in the currently selected domain or have specific characteristics in that domain. From the nodes in the Domain context tree you can call related actions by opening the context menu.

If you access a freshly installed Application Server Database you will see the predefined Root domain only. The root domain cannot be deleted and you cannot add other root domains, i.e. you cannot create domains without a parent.

Domain tree

The domain tree uses different icons for domains to distinguish domains with different characteristics. See table 1 for an explanation of these icons.

Icon | Usage
 | Regular domain
 | Identity domain

Table 1: Different icons used in the domain tree and their meaning

From the Domain explorer you can create features and sensors. The features and sensors created will always be bound to the the domain for which they were created.

The creation of features can be initiated from the context menu item Create features in the context menu of a domain in the domain tree, in the context menu of a feature type in the domain context tree and in the context menu of a feature subtype in the domain context tree. The Create features window will be called and the values for domain, feature type and feature subtype will be filled accordingly.

The creation of sensors can be initiated from the context menu item Create sensors in the context menu of a domain in the domain tree and in the context menu of a sensor type in the data domain context tree. The Create sensors window will be called and the values for domain, sensor type will be filled accordingly.

Since there can be only one root domain and since this root domain is always present you can create new domains only as subordinate domains of existing domains. The menu item Create subordinate domain in the context menu of a domain will open the Create domain window with the parent domain already filled.

To edit a specific selected domain choose Edit from the context menu of the domain. This will bring up the Data Domain window where you can modify the properties of the domain. Note you will have to reload data in the Data Domain explorer after modifying a domain.

To set a domain as Identity domain you select the Is Identity domain toggle menu item in the context menu of the domain. You need the appropriate permissions to perform this action. Note that a domain cannot be mad an identity domain if it contains features that violate the rules of identity domains.

Sensors, Alias schemes Axes and Approval Templates bound to a specific domain can be opened directly from the context menu of that domain.

The Available feature types context menu item will start the Available feature types window where you can define which feature types will be available in this domain.

Selecting Privileges from the context menu will start the Domain privilege window for displaying or modifying the privileges of users and user groups on the selected domain.

To delete a domain select Delete from the domain's context menu. Note that deleting a domain is only possible if no data is bound to that domain.

Date domain context tree

The domain context tree gives access to different objects that are defined or configured within the context of a domain. Among them presentation templates, feature types, axes, cross sections, classification types and classifications, approval templates and others more.

For reasons of usability not all root nodes of the domain context tree are visible by default. Every user can configure the visible nodes by selecting Customize visibility of context nodes from the window's toolbar (figure 1:3)

Figure 1: The domain explorer window with the context menu for a domain


Domain privilege

Last edited: 10/5/2017 11:51:36 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Navigation: Smart Client > Windows > Domain & Context >

Feature Subtypes

Last edited: 3/8/2018 7:30:14 AM


Create Feature Subtype

Last edited: 10/5/2017 11:51:36 AM

The Create Feature Subtype window is a modal window used to create a feature subtype for a specific feature type. The window can be opened from the Data Domain Explorer in the Data Domain Context area. Under Feature types select the feature type you want to create a subtype for and then select Create feature subtype from the context menu of the feature type.

To create feature subtypes you need the Feature type permission Modify feature subtypes (3).

The Name of the feature subtype is mandatory. domain that you type in the Name box must be unique among all domains with the same parent domain.

Note that deleting feature subtypes and all other tasks concerning feature subtypes are initiated from the context menu of that feature subtype in the Data Domain Context area of the Data Domain Explorer.

Figure 1: The Create Feature Subtype Window


Edit Feature Subtype

Last edited: 10/5/2017 11:51:38 AM

The Edit Feature Subtype window is a document window used to display and modify the properties of a feature subtype. The window can be opened from the Data Domain Explorer in the Data Domain Context area. Under Feature types select the feature type for which you want to edit a feature subtype, select Feature subtypes and then select the subtype you want to edit. From the context menu of this subtype select Edit.

The Domain box displays the domain to which the feature subtype is assigned. The Feature type box displays the feature type to which this subtype belongs. Both of these boxes are read only.

The Name of a feature subtype must not be empty, use the Description to describe the usage of the feature subtype.

Figure 1: The Edit Feature Subtype Window


Feature type privilege

Last edited: 10/5/2017 11:51:38 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Map file set

Last edited: 10/5/2017 11:51:38 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Map file sets

Last edited: 10/5/2017 11:51:38 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Navigation: Smart Client > Windows > Domain & Context >

Sensors

Last edited: 10/5/2017 11:51:40 AM


Create Sensors

Last edited: 10/5/2017 11:51:36 AM

The Create Sensors window is a modal window used to create sensors within a domain. The window can be opened from the context menu of a domain in the Data Domain Explorer.

The window is used to create one or more sensors, in the domain the window was started from.

To create sensor types in a domain you must have the domain permission Modify sensors (12) and the feature type permission Modify sensors (1) on at least one feature type the sensor type you selected is associated with.

The Domain box shows the domain in which the new features will be created. Note that the selected domain is the domain from which the window was opened.

The Sensor type drop-down list defines the sensor type of all sensors to be created. A sensor type has to be selected here to enable further controls.

In the Sensor names box you can specify names for new sensors. Each sensor must be separated by a new line. Note that the name for a sensors is limited to 200 characters.

To open the sensor immediately after creation select the Open first crated sensor check box. If you create more than one sensor this will still only open the first created sensor.

The Ok button will only be enabled if a sensor type and at least one sensor name have been defined.

Figure 1: The Create Sensors window


Sensor

Last edited: 10/5/2017 11:51:40 AM

The Sensor window is a document window that is used to display and modify a specific sensor. You can open this window from the context menu in the sensors list of the Sensors window.


SensorConfigurationEditorView

Last edited: 10/5/2017 11:51:40 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Sensors

Last edited: 10/5/2017 11:51:40 AM

The Sensors window is a document window used to display create and modify sensors in a specific context. The window can be opened from the Data Domain window either directly from the context menu of a domain or form the context menu of a sensor type in the Context tree of a domain.

When opened from the domain node in the Data Domain Explorer the window will list all sensors defined in that domain (i.e. sensors of any sensor type). When opened from the context menu of a sensor type only sensors of this type will be shown. In any case sensors that are defined in parent domains will also be listed.

The Info bar shows for for which context the sensor list is shown.

Double click a row in the grid or select Edit from its context menu to open up a Sensor window where you can modify the selected sensor.

You can delete the selected sensors by selecting Delete from the context menu. Note that you cannot delete sensors as soon as they are used in features (as default sensor) or in observations (as actual sensor used).

To create a new sensor select Add from the toolbar, this will bring up the Create Sensors window. If the Sensors window was opened in the context of a specific sensor type the Create Sensors window will have this type selected on startup.

Figure 1: The Sensors window


Presentation

Last edited: 10/5/2017 11:51:32 AM

This chapter describes windows used for creating and executing presentations. For every type of presentation Redbex can store presentation templates i.e. reusable blueprints for presentations. Those templates will then be available from the domain context in the domain window.


Chart

Last edited: 10/5/2017 11:51:36 AM

The chart window is a document window used for creating a chart definition and executing the definition i.e. displaying the chart. This window is used for charts of type time value, cross, and axis.

The window can be opened from the Ribbon' Presentation tab by selecting Time chart, Axis chart or Cross chart, or from the Data Domain Explorer window by selecting a chart template and then selecting Create presentation from the context menu.

The Chart tab shows several different areas. The Data source area area (figure 1:1) that is further divided into the Data source pins (figure 1:2) and the Features on selected pins (figure 1:3) area is used for defining the data binding of the chart. The Data source area can be collapsed (figure 1:4) to have more space for the chart itself (figure 1:7).

The Settings area to the right of the window (figure 5) shows a property grid that is used for specifying the settings for the whole chart for the currently selected pin in the Data source pins area or for the currently selected selected feature in the Features on selected pin area. The Settings area can be collapsed (figure 1:6) to have more space for the chart itself.

The central area of the window (figure 1:7) is used for displaying the rendered chart.

Figure 1: The Chart tab of the chart window (here opened for a time chart)

To specify settings for the whole chart choose Show chart settings from the window's toolbar. The available chart settings will then be shown in the property grid in the Settings area. Which settings are available depends on the specific chart type the window was opened for.

In the Data source area you define what data shall be displayed in the chart. To display the observations of a feature in a chart you first have to define a pin.

If you open the chart window from the Ribbon (and not form a presentation template or presentation template binding one data source pin with will be already created and will be shown in the Data source pins area. To create a new pin select Create pin from the window's toolbar. Note that the chart type might restrict the number of pins you can create. You can rename a pin by selecting the pin and then pressing F2 or by selecting Rename from the context menu.

Before you can link features to a pin you will first have to type the pin. This is done by selecting the pin and then choosing the feature type in the property grid in the Settings area. As soon as a pin is typed you can drag feature of that type into the Features on selected pin area to link features to the currently selected pin. Only features of the selected type can be linked to a pin. To remove feature from the list of features that are linked to a pin, select the pin, then select the feature you want to remove in the Features on selected pin area, and then either hit the [Del] key or choose Delete from the context menu.

The settings for a specific feature linked to a pin a re shown in the property grid of the Settings area when the feature is selected in the Features on selected pin area.

As soon as all required settings were taken you can execute the chart definition by selecting Execute from the window's toolbar. If any settings are missing or invalid this will be reported in the output window.

The Filter tab allows to specify a time filter that will can be applied to all data presented with the chart, i.e. if the time filter is applied only observations with a sampling timestamp that matches the filter will be shown in the chart.

Select Apply time filter to enable time filtering for the chart. If this checkbox is not selected the time filter (even if configured) will not be applied. You can select between a static time span or dynamic time span for filtering by selecting the appropriate value from the Filter type list box, this will then show the control block for either the static or dynamic time span.

Figure 2: The Filter tab of the chart window, showing the control the dynamic time span control block

Saving as template

The chart definition created in this window can be saved as a presentation template and/or as a presentation template binding. Selecting Save from the window's toolbar will open the window modal dialogue for saving (figure 3).

If you want opened the window from a presentation template or a presentation template binding the controls in this dialogue will be already filled. If the chart was not opened from a presentation template or a presentation template binding the controls will be empty.

To save the current chart definition as presentation template type a name and optionally a description in the Save template group box. The Private checkbox defines if the template will only visible to you or will be generally visible to all users. Select a domain in which the template shall be stored by dragging a domain from the Data Domain Explorer to the Domain drop. Select Save to store the template. Note that if the chart definition was opened from an existing template the template will be overwritten. If not the template will be created. Select Save copy if the chart definition was opened from a template but you wan to store it as a new template.

To save the current bindings as presentation template binding you will have to save the template first. Type a name and optionally a description in the Save bindings group box. The Private checkbox defines if the template and data binding will only visible to you or will be generally visible to all users, the private checkbox is only effective if the template the binding is saved for is not private.

Note that if the chart definition was opened from an existing presentation template binding the template binding will be overwritten. If not the template will be created. Select Save copy if the chart definition was opened from a presentation template binding but you want to store it as a new presentation template binding.

Figure 3: The Save template and bindings window modal dialogue


%Text%

Navigation: Smart Client > Windows > Presentation > Chart >

Dynamic pins

Last edited: 10/5/2017 11:51:14 AM

Pins in a chart definition can be defined as dynamic (figure 1:1). If a chart contains at least one dynamic pin the chart definition will show a drop area for dynamic content (figure 1:2). Whenever you drop features on the bindings for all pins flagged as dynamic will be changed, currently bound features will be unbound from those pins and the newly dropped features will be bound.

This is especially useful if your chart definition has several pins showing different properties of the same feature(s), e.g. when having a chart definition with three pins showing the X, Y, and Z coordinates of a 3D measurement point.

Figure 1: Dynamic pins for chart templates


Map view

Last edited: 10/5/2017 11:51:38 AM

The Map View window is a document window used for creating Map View definitions and executing those definitions i.e. rendering maps.

The window can be opened from the Ribbon' Presentation tab or from the Domain Explorer from a map view template.

Figure 1: The Map View window showing a simple map

The Map view tab (figure 1:1) shows several different areas. The Data source panel (figure 1:2) is an expandable panel used for defining layers and binding content to layers. In the upper part of this panel a list box shows all currently defined layers. You can add new layers by selecting the Add layer menu button (figure 1:3) and then selecting the type of layer you want to add. The layers in this list are ordered in their rendering sequence, i.e. the first layer in the list will be rendered first and will therefor be the bottommost layer. You can reorder the layers and therefore their rendering sequence using drag & drop. To rename a layer click the Rename button tat appears when you hover the mouse over the layer.

In the Features and views list box you can bind features or views to the currently selected layer by dragging them from the Feature Explorer to this list box. Note that only some layers support binding of features and views, and the layer might restrict that types and number of features you can bind.

The Toggle clear before drop toggle button on just above the Features and views list box defines the behavior when dropping features or views. If enabled the list of features is automatically cleared before you drop new elements, if not enabled newly dropped elements are just added to the list. The Toggle execute after drop toggle button defines if after dropping elements to the Features and views list the Smart Client shall automatically redraw the map.

The Configuration panel to the right of the window (figure 1:4) shows a UConfiguration property grid that is used for displaying and modifying the Map Configuration and the configuration of each individual layer. To show the Map Configuration select Show map view configuration from the window's toolbar. To show the configuration of a specific layer just select that layer in the layers list box. For a documentation of each setting in these UConfigurations please refer to the Application Server documentation.

The central area of the window is used for displaying the rendered map. To execute a map view definition and select Execute from the window's toolbar or press F5. As soon as a map is rendered you can move the shown map by left click and mous move, the zoom level can be changed with your mouse wheel. To return to a full-extent view select Zoom to full extents from the window's toolbar.

The window's toolbar (figure 2) provides commands for modifying the map view definition and for working with the displayed map.

The Add Layers menu button shows all available types of map layers. By selecting one of these layer types a new instance of that layer type is added to the map view definition.

Selecting Show map view configuration will show the global configuration of this map view in the property grid of the Configuration panel.

The Execute button will actually execute the map view definition and render the map.

The Zoom extents button will zoom to the extents of the map view contents.

To save the map view definition (optionally together with the Bindings select Save, the currently rendered map view can be copied to the Clipboard, can be printed directly or can be saved to a bitmap by selecting respective buttons from the toolbar.

Selecting one of the the tool buttons from the window's toolbar (figure 2:1) will activate a specific map tool that allow you to interact with a rendered map view. Once activated most map tools will display additional buttons in the map area.

Figure 2: The Map View window's toolbar


Annotation tool

Last edited: 10/5/2017 11:51:28 AM

This topic is not yet finished in this version of the Reference Manual. A later version of this Reference Manual might be available online please visit http://doc.redbex.com/. Please contact support if you need more information regarding this topic.


%Text%

Navigation: Smart Client > Windows > Presentation > Map view >

Measuring tool

Last edited: 10/5/2017 11:51:28 AM

This topic is not yet finished in this version of the Reference Manual. A later version of this Reference Manual might be available online please visit http://doc.redbex.com/. Please contact support if you need more information regarding this topic.


%Text%

Navigation: Smart Client > Windows > Presentation > Map view >

Feature selection tool

Last edited: 10/5/2017 11:51:28 AM

The feature selection tool allows you to select features on a map view and add these features to the current feature selection.

Features are selected by drawing a shape (the selection shape) on the map, the selection will then include all features that have an LSO that is intersecting the drawn shape. Table 1 shows the different ways of defining the selection shape with this tool.

The result of the selection will be added to the feature selection.

Selection shape drawing | Description
Point & Buffer | The selection shape will be a polygon that is created from the drawn point and the specified buffer. I.e. the selection shape will be a discretized circle shape)
Line & Buffer | The selection shape will be a polygon that is created from the drawn line by applying the specified buffer.
Polygon | The selection shape is exactly the drawn polygon shape.
Rectangle | The selection shape is exactly the drawn rectangle shape.

Table 1: Different ways how to draw a selection shape


%Text%

Navigation: Smart Client > Windows > Presentation > Map view >

LSO definition tool

Last edited: 10/5/2017 11:51:28 AM

This topic is not yet finished in this version of the Reference Manual. A later version of this Reference Manual might be available online please visit http://doc.redbex.com/. Please contact support if you need more information regarding this topic.


%Text%

Navigation: Smart Client > Windows > Presentation > Map view >

DEM Tool

Last edited: 10/5/2017 11:51:28 AM

The DEM map tool provides the possibility to query the elevation of a specific point on the map, according to a digital elevation model stored with a specific projected coordinate system. You can activate this tool by selecting the DEM tool button in the Map View window's toolbar (figure 1:1).

This map tool will show a set of controls in the map area. First select the projected coordinate system in which you want to query the elevation (see chapter Digital Elevation Models for more details about digital elevation models in Redbex)

To measure the elevation of a specific point on the map select Point button in the map tool controls and click on the map. The elevation will be queried and will then be shown as a label on the map (see figure 1:3). If there is no DEM covering that specific point the label will show no coverage, if there is a DEM covering the point but the DEM does not include an elevation for that specific position not defined will be shown.

The labels for each measurement are temporary and are not persisted with the map view definition.

To remove labels select the Eraser button in the map tool controls (figure 1:3).

Figure 1: The DEM tool in the Map View window


%Text%

Navigation: Smart Client > Windows > Presentation > Map view >

To-scale PDF

Last edited: 10/5/2017 11:51:28 AM

The To-Scale PDF map tool provides the possibility to generate a PDF document that contains the contents of the map view and is in a user-defined scale.

You can activate this tool by selecting the To-Scale PDF button in the Map View window's toolbar (figure 1:1).

The Scale and DPI setting for the PDF to be created can be defined by the user. Scale can be a value between 100 and 1,5E08, DPI is a value between 5 and 300. Note that scale factor and DPI define the paper size of the created PDF as well as the size of the PDF in bytes. Several limitations apply for both sizes, see chapter To-scale map view PDF for more details.

Selecting Execute will start a job on the Application Server that creates the to-scale PDF file. The file will then be available via the Output files window.

Note: To preserve the scale when printing the PDF you will have to download the PDF and open it in a PDF viewer that that supports unscaled printing.

Figure 1: The To-scale PDF tool


Axis Section Drawing

Last edited: 10/5/2017 11:51:36 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


CAD Map

Last edited: 12/6/2017 10:30:54 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Server Administration

Last edited: 10/5/2017 11:51:40 AM

This chapter describes Smart Client that are used for administrating the Application Server.


Authentication Log

Last edited: 10/5/2017 11:51:36 AM

The Authentication log is a document window used to display all authentication attempts (successful or not) that were made. You need special system permissions to list authentication attempts. The window can be opened from the Administration Ribbon tab.

The window shows all authentication attempts in the time span selected in the tool bar.

When selecting delete in the toolbar all Authentication attempts in the selected time span that are not associated with a user session will be deleted.

Figure 1: The authentication log window


Change Password

Last edited: 10/5/2017 11:51:36 AM

The Change password window is a modal window that is used to change the password of the currently logged on user. The window can be opened from the Administration Ribbon tab.

You have to provide the current password of your user account and a new password. Note that the OK button will be enabled only if the new password is different from the old password.

Changing your password will fail if the new password does not match the password quality rules enforced by the Application Server. In that case the window will not be closed after selecting OK. The reason for the failure will be written to the output window.

Figure 1: The Change Password window


Create User Group

Last edited: 10/5/2017 11:51:36 AM

The Create User Group window is a modal window used to create user groups. The window can be opened from the toolbar in the User & User Groups window (for root groups) or from the context menu of a user group in the User & User Groups window (for subordinate groups).

To create a new user group you need the system permission Manage users and user groups (0).

The Name of the user group is mandatory.

Figure 1: The Create User Group Window. In this case the window was opened for creating a new root user group.


Create users

Last edited: 11/8/2017 9:24:06 AM

The Create Users window is a document window used to create one or more new Redbex users. The window can be opened from the toolbar in the User & User Groups window.

To create new users you need the system permission Manage users and user groups (0).

The window contain a grid control where in each row of the grid you can specify the data for a new user to be created. To add a row to the grid select Add from the window's toolbar.

For each user you have to specify a unique username and an e-mail address. Rows the username or the e-mail are empty or the e-mail address is not a valid email address are ignored. Note that the e-mail address will be used to send login data to the user.

Data in all other columns is optional. Please see chapter User for a detailed explanation of all properties that can be set for a user.

Importing from a text file

The grid can also be populated with data from a delimited text file. The order of the columns in the text file has to follow the layout of the shown grid, i.e. the text file must columns with the same content in the same order. It is however allowed to have less columns than shown in the grid. E.g. you may have a text file with only username and email address. The columns in the text file can be delimited with tab, colon or semicolon, however the same delimiter must be used throughout the whole file. The system will detect the used delimiter by inspecting the first line of the file. This line is regarded as header line and will not be added to the grid.

Example file 1: Semicolon separated text file for importing user data. This file includes all columns supported

Example file 2: CSV file for importing user data. This file includes all columns supported

Example file 3: Tab delimited file for importing user data, this file includes only the first 3 columns

After the grid has been filled with the data for the users to be created select Create users from the Toolbar to actually create the users. Users that could be created will be removed from the grid, users that could not be created will stay in the list, look at the output messages for more details.

Figure 1: The Create users window


DEM Editor

Last edited: 10/5/2017 11:51:36 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


DEM List

Last edited: 10/5/2017 11:51:36 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Feature Type editor

Last edited: 10/5/2017 11:51:38 AM

The Feature Type Editor window is a document window that can be used to globally specify some settings of for feature types. The window can be opened from the ServerAdministration Ribbon.

The list on the left side of the window shows all available feature types. Selecting one feature type in this list will show details for this feature type on the right side.

The Path is a read-only text box and shows the default grouping path for the feature type.With the custom path text box the default grouping path can be overridden. Note that the custom path can be set for any of the supported languages. Use the language picker control to define the grouping path for different languages.

Figure 1: The Feature Type Editor window


Global Settings

Last edited: 10/5/2017 11:51:38 AM

The Global Settings window is a document window that is used to display and modify the global settings used to configure some basic properties of the Application Server. The window can be opened from the Administration Ribbon tab.

Global Settings can be read by any user but can be modified only by users with the system permission Modify global settings (4). The property grid might therefore be read-only.

Global settings are displayed and modified using a property grid.

Be careful with modifying global settings, since they may greatly influence security and performance of the Application Server.

Figure 1: The Global Settings window


License Retrieval

Last edited: 10/5/2017 11:51:38 AM

The license retrieval window is a modal window that can be used to download and install a license code from the Distribution Server. The window can be opened from the Ribbon's Server Administration tab.

To download a license you have to provide the product key that was given to you when you purchased a license of Redbex.

After selecting OK the Smart Client will request the license code from the Application Server. The results of this request will be shown as output message.

Figure 1: The license retrieval window


License Information

Last edited: 10/5/2017 11:51:38 AM

The License Information window is a document window that is used to show the currently installed license code of the currently connected Application Server. The window is opened from the Ribbon's Server Administration Tab.

Data displayed in this window is read-only.

Figure 1: The License Information window


%Text%

Navigation: Smart Client > Windows > Server Administration >

Message delivery logs

Last edited: 10/5/2017 11:51:38 AM

The Message delivery logs window is a document window that can be used to access the message delivery logs stored within the system for each sent message. The window is opened from the Ribbon's Server Administration Tab.

Message delivery logs are written by the system to investigate problems with message forwarding and delivery (e.g. if an SMPP server is not reachable for message forwarding). Only Sender sent date and subject of the message will be shown the message body will not be accessible from this window.

The filter area allows you to limit the number of messages shown in the message grid. The filter area can be shown / hidden by selecting Show / hide filter area from the window's toolbar.

From and To are used to filter by send date. Default values for from and to will be chosen by the Smart Client, you can change them but From and To always have to have a value.

Sender can be used to filter for messages sent by a specific user. This filter is optional and can be left null to not apply a sender filter.

Recipient can be4 used to filter for messages that were addressed to a specific user. Each message where one of the recipients is the specified user will match this filter. This filter is optional and can be left null to not apply a recipient filter.

After changing a filter criteria select Reload from the window's toolbar.

The message grid shows all messages that match the current filter criteria. Messages are shown in pages. The grid columns show some basic information for each message. Double clicking a row in the grid or selecting Show log from the context menu of a grid row will load and show the actual message delivery log in a separate window.

Figure 1: The Message delivery logs window


System privilege

Last edited: 11/8/2017 9:27:20 AM

The System privileges window is a document window used to display and modify the privileges on the system.

The window can be opened from the Ribbons Server Administration tab. The information bar shows the object type and the privilege object which in case of system privileges are always System.


General text templates

Last edited: 10/5/2017 11:51:40 AM

The General Text Templates window is a document window used to display and modify some predefined Text Templates used by the Application Server (General Text Templates). The window can be opened from the Ribbon's Server Administration tab.

With the Template type drop down you select the type of template you want to display or modify, with the Template language drop down you select the language of the template you want to edit. As soon as type and language are selected the associated template text is shown, to modify the template text select Edit from the window's toolbar. This will open the Text Template Editor window.

Attention: General text templates are important for the Application Server. Emptying a text template or providing a syntactically wrong text template may hinder you in the operation of your Application Server. Please always make a backup before modifying a General text templates.

Figure 1: The General Text Templates window


User

Last edited: 10/5/2017 11:51:40 AM

The User window is a document window used to display and modify the properties of a user including the group memberships. This window can be opened from the Users & User Groups by selecting Edit from the context menu of a specific user.

You need the system permission Manage users and user groups (0) to edit a user.

On the General tab you can modify the details of the user. Picture can be used to store a picture of the user. Select Change Image from the context menu to select a picture of the current user. The Smart Client will automatically resize the selected image to a maximum size of 400 x 400 pixel.

The User name is mandatory and has to be unique, i.e. all users have to have a unique user name. Leading or trailing blanks will be automatically removed by the Application Server.

The Email address is mandatory and has to be a (syntactically) valid email address the Application Server validates the email address upon save and save will fail if an email address is found to be not syntactically valid the user cannot be saved.

On the Membership tab the current memberships, i.e. groups the users is assigned to, are displayed and memberships can be modified. Note that on the membership grid you see only the direct memberships of the user. I.e only the groups the user is directly assigned to. Since memberships are propagated upwards in the Group tree the user might be member of parent groups also.

To add the user to other user groups drag the user groups from the Users & User Groups window onto the grid. To remove the user from a user group select the group in the grid and then select Delete from the context menu.

Figure 1: The User Window showing the General tab

Figure 2: The User Window showing the Memberships tab


User & User Groups

Last edited: 11/8/2017 9:24:20 AM

The User & User Groups window is a tool window that shows all users and user groups. You can start this window from the Ribbon's ServerAdministration tab. In many places where you can select a user, a set of users, a user group or a set of user groups by using drag and drop this window is needed as the drag source.

The window consists of two areas: The upper area shows a Grid with all users. The toolbar button Show inactive users specifies if this grid will either include all active users or all active and all inactive users.

From the context menu of a user selected in the grid you can select User information to open the User Information window for that user and show the publicly available information of that user.

To modify a user select Edit from the context menu this will bring up the User window for the user you want to modify. You need the system permission Manage users and user groups (0) to modify a user.

Users with the system permission Manage users and user groups (0) can send a test email to a list of selected users. This can be used to verify the email address stored with that user and also to verify the SMTP settings (specified in Global Settings). Selecting Send Test Email from the context menu of the selected users will send a separate test email to each of the selected users.

Users with the system permission Manage users and user groups (0) can reset a user's password if the user is not an Active Directory user. By selecting Reset password from the context menu of a user in the grid a new password (randomly created by the Application Server) will be set for the user and an email will be sent to the user. Note that the user resetting the password will never know the new password.

To delete a user select Delete from the context menu of that user. Deleting a user will only work if there is no other data associated with that user. If so set the user inactive instead.

To create a new user select Create user from the window's tool bar.

You can select one or more users (grid rows) and drag them to other windows.

The lower area of the window shows a tree view with all user groups. The tool tip for a user group node shows the description of the user group if available.

To modify the data of a user group (including the members of that user group) select Modify from the context menu of that user group.

To delete a user group select Delete from that user groups context menu. Deleting a user group will also delete all its subordinate groups.

To create a new root user group, i.e. a group with no parent select Create user group from the window's toolbar. To create a subordinate group of an existing group select Create subordinate group from the context menu of the parent group in the group tree.

You can select one or more user groups in this tree and drag them to another window.

Figure 1: The User Explorer


User Group

Last edited: 10/5/2017 11:51:40 AM

The User group window is a document window used to display and modify the properties of a user group including the user memberships. This window can be opened from the Users & User Groups by selecting Edit from the context menu of a specific user group.

You need the system permission Manage users and user groups (0) to edit a user group.

On the General tab you can modify the name and description of the user group. The parent group (if any) is shown but cannot be edited.

On the Members tab the current members, i.e. users that are member of the group, are displayed and memberships can be modified. To add a new member to the group drag the user(s) from the Users & User Groups window onto the grid. To remove members from a user group select the member in the grid and then select Delete from the context menu.

Figure 1: The User Group window with the General tab

Figure 2: The User Group window with the members tab


User Information

Last edited: 11/8/2017 9:24:06 AM

The User Information window is a document window that displays the public details about a user. You can open this window from the User explorer.

The window does not allow any changes to data, and will display only data for which the accessing user has the appropriate permissions.

Figure 1: The User Information window


User Profile

Last edited: 11/8/2017 9:24:06 AM

The My Profile window is a document window that can be used to modify the details of the user account of the currently logged in user. You can open this window from the Ribbon's Administration Tab.

The window shows the data stored with the user account. All shown data with the exception of the user name can be changed. The user name can only be changed by users with the appropriate permissions in the User Management window.

To add or change the image associated with your user account select Change image from the images context menu.

Use the Published extended information check box to define how much information shall be visible to all users of that Application Server. See chapter User for more details.

Figure 1: The My Profile window


User Sessions

Last edited: 10/5/2017 11:51:40 AM

This document window allows monitoring and managing open and closed user sessions. You can start this window from the Ribbon's Administration tab.

The Open tab on the window shows a grid with all open user sessions. Each grid row displays information about one open user session, in the expansion area of each grid row detailed client information is displayed. The State column displays the status of the open user session.

To close an open session (i.e. kick a user from the Application Server) select Close session in the context menu of a user session.

The Closed tab shows user sessions that are already closed. Due to the possibly huge amount of sessions the sessions are displayed separately for each user. If this page is active the toolbar provides the possibility to delete historic user sessions. You can select a data and after selecting Delete all closed sessions before this date will be deleted.

Figure 1: The User sessions window

Figure 1: The User sessions window


Smart Client configuration

Last edited: 10/5/2017 11:51:40 AM

This chapter describes Smart Client that are used for administrating the Smart Client.


Application Server Connections

Last edited: 10/5/2017 11:51:36 AM

The Connection manager is a document window is used to define connections to Application Servers. The window can be started from the Backstage menu. If no Application Server connections are defined this window will be started automatically when the Smart Client starts up.

An Application Server connection is a named set of settings that need to be specified to be able to connect the Smart Client to an Application Server. You can create and manage any number of Application Server connections with this window. The connections defined in the Connection Manager will be available in the Connect to Application Server window.

To define an Application Server connection you have to know some details about the configuration of the Application Server you want to create a connection for. Usually you will receive the settings together with your login data for an Redbex Application Server.

You have to create Application Server Connections in the Connection Manager before you can connect to an Application Server.

Figure 1: The Connection manager window, showing a typical connection for an Application Server installed in the local network.

The list on the left side of the window (Figure 1) shows the currently defined connections. The connections in this list are shown with their name and a summary of connection settings. The icon for the list element shows if the connection is a regular connection or the default connection.

On the right side the window displays details of the connection currently selected in the list.

The Name box specifies the name of the connection and is used to identify the connection in the Connect to Application Server dialogue. Each connection must have a unique non empty name.

The Communication protocol drop down list defines the network protocol used to access the Application Server. Note that wile you can select from all protocols that are theoretically supported by the Application Server, your Application Server might not be configured to allow connections with all these protocols and also not all protocols might be suitable for the network connection between the Smart Client and the Application Server. E.g. it is unlikely that the TCP connection protocol will work if you access the Application Server from outside a local area network.

In the Server address box you type the address of the Application Server. For connections over the internet this is usually a DNS name like myserver.mydomain.com, for local area network connections the name is usually just the host name like myserver, if your Application Server runs on the same machine as the Smart client you can use localhost. The Server address can also be specified as IP address like 192.168.0.3.

Each Instance of an Application Server provides its services with a specific service path. In the Service path box you specify the service path of the Application Server Instance you want to connect to. If not configured differently by the administrator of your Application Server the service path is by default redbex .

The Port box defines the network port on which the Application Server listens for service requests. If not changed by the Administrator of your Application Server the default port for connections using HTTP is 80, for connections using TCP 5660, and for confections using HTTPS 443. The port is a positive integer between 1 and 65535.

The maximum user session idle time is the time span after which the Application Server will consider a user Session initiated by a login as ended and will automatically close this session. The Application Server defines a default, a minimum and a maximum for this idle time. The Smart client can request a timeout different from the Application Server's default. In the Requested user session timeout box you can define the maximum user session idle time the for user sessions that the Smart Client will request from the Application Server. The value specified here is a suggestion that the client will send to the Application Server on Login. The Application Server will set the actual maximum user session idle time according to the defined minimum and maximum value.

The User name and Password boxes can be used to predefine the username and optionally password for the connection. These two boxes need not to be filled if you prefer to type username and password each time you connect to the Application Server. When entered the password is stored on the Computer where the Smart Client is installed (the stored password symmetrically encrypted using Windows' Data Protection API).

The Preferred date time offset is the offset in which the Application Server shall present date & time values. See chapter Date time offset for more details.

The Send timeout, Open timeout, Close timeout and Receive timeout boxes allow fine grained control of various timeouts that apply to the communication between Smart Client and Application Server. The default values set for newly created connections will work in most cases. However you can change the values to fit the capabilities of your IT environment. Note that when accessing specific services the Smart Client and the Application Server might negotiate different timeouts, e.g. when transferring binary files.

The Send timeout defines how long the Smart Client will wait for a response from the Application Server service. The Open timeout is the amount of time the Smart Client will wait when opening a connection the Application Server. Similarly, the Close timeout is the amount of time that the Smart Client will wait for (successfully) closing a connection. The Receive timeout is the maximum time the Smart Client can take to process the result of a service call.

Setting the default connection

From the context menu of a list item you can set the selected connection as the default connection. The default connection is the connection the Smart Client will automatically select in the Connect to server window when it is started. There can be only one default connection, i.e. if you set a connection as default connection a previously defined default connection will be reverted to a regular connection.

Testing connections

Application Server connections can be tested in the Connection Manager. To do so choose Test from the context menu of an entry in the list box of Application Server Connections. The result of the connection test will be shown next to the Name of the connection in the list of Application Server connections.

The test will be performed with the connection settings even if those settings were not saved yet. Note that for really creating a connection with modified settings you have to save those settings first.

Note that the connection test address, port and protocol, user credentials are not tested.


Smart Client Settings

Last edited: 10/5/2017 11:51:40 AM

The Smart Client Settings document window allows you to configure some settings that influence the behavior of the Smart Client. The Smart Client Settings window is opened from the Backstage Menu on the Smart Client Administration tab.

Refer to chapter Smart Client Settings for a description of each setting shown on this window.

Figure 1: The Smart Client Settings window


Administration

Last edited: 10/5/2017 11:51:02 AM

Following chapters give detailed information about the Smart Client that are useful for administration of the Smart Client.


Directory environment

Last edited: 10/5/2017 11:51:34 AM

Below you find an (incomplete) listing of directories used by the Smart Client. All of these directories are based on Windows special folders or on Windows environment variables, so the actual path of those directories depends on the configuration of your windows environment.

Application directory

<ProgramFiles>\Redbex\Smart Client\

All executable files some configuration files and and accompanying directories are installed here. <ProgramFiles> is a Windows special folder that is usually points to something like C:\Program Files. The Windows environment variable %ProgramFiles% can be evaluated to show the location of this special folder. Type echo %ProgramFiles% in a console window.

Common Application Data directory

<CommonApplicationData>\Redbex\Smart Client\

Folder is used for all data that is specific to one computer but available for all users. Examples are the files for Smart Client common settings, and Application Server Connections

Roaming application data directory

<ApplicationData>\Redbex\Smart Client\

Windows user specific data persisted by the Smart Client across sessions. <ApplicationData> is a Windows special folder that usually points to something like C:\Users\user1\AppData\Roaming. The Windows environment variable %AppData% can be evaluated to show the location of this special folder. Type echo %AppData% in a console window.

The <ApplicationData> directory serves as a common repository for application-specific data for the current roaming user. Data in this directory is copied between machines when roaming profiles are enabled (in a Windows domain environment).

Local application data directory

<LocalApplicationData>\Redbex\Smart Client\

This folder is used by the Smart Client for Windows user specific data that shall be persisted across sessions but shall not be copied between machines in a Windows domain environment. <LocalApplicationData> is a Windows special folder that usually points to something like C:\Users\user1\AppData\Local.

Log files directory

<Local application data directory>\Logs\

This sub folder of the local application data directory is used by the Smart Client for storing log data. On startup The Smart Client will automatically delete log files in this folder that older than 10 days.

Downloads directory

<Local application data directory>\Downloads

This folder is used by the Smart Client to store files downloaded from the Application Server. On startup the Smart Client will delete all files from this directory.

Temporary directory

<TemporaryDirectory>\Redbex\Smart Client\

During execution the Smart Client needs a place where it stores data temporarily. This data is stored in the temporary directory. <TemporaryDirectory> is evaluated by checking the existence of environment variables in the following order and using the first path found:

1.The path specified by the TMP environment variable.

2.The path specified by the TEMP environment variable.

3.The path specified by the USERPROFILE environment variable.

4.The Windows directory.

Type SET in a console window to show all of the defined environment variables.

On startup The Smart Client will automatically delete log files in this directory that older than 2 days.


Logging

Last edited: 10/5/2017 11:51:34 AM

The Smart Client logs information that might me valuable to administrators or support personnel for tuning performance, tracking down configuration errors and finding reasons for errors. The data logged is logged in form of log entries that contain textual information in English language together some metadata as described in table 1.

For a persistent record of this data the Application Server makes use of its own logging engine that persists log messages according to a default log configuration.You may override this default behavior by providing your own nlog.config file in the Smart Client Application directory, for more information on creating custom log configurations visit the NLog website. The Logging chapter for the Application Server also lists examples for custom logging configuration.

The default logging configuration for the smart clients writes all log messages to files in the log files directory.

Log files are named like Smart Client Log <YYYY-MM_DD hh:mm:ss>.txt. The files contain the time stamp, the log level and the message of the log entries. The date encoded in the file name is the date of the first entry in the log file.

All log data with a Log level of Error or Fatal will be additionally written to the Windows Event Log. The event log entry will contain the time stamp, the log level and the message of the log entries and if the log entry contains an exception also the textual representation of that exception. The Event log entries are written to the Application Event log and the source for the entries is Application.

For debugging and support important log messages are logged directly a logentries.com account owned by Pöyry Infra GmbH.

Whenever the Smart Client encounters an unexpected problem, and therefore shuts down unexpectedly it will also copy some error information to the Windows Clipboard.

Log entry element

Description

Time stamp of logging

Date and time when the log entry was generated

Message

Textual information

Log level

·Trace - very detailed logs, which may include high-volume information such as protocol payloads. This log level is typically only enabled during development

·Debug - debugging information, less detailed than trace, typically not enabled in production environment.

·Info - information messages, which are normally enabled in production environment

·Warn - warning messages, typically for non-critical issues, which can be recovered or which are temporary failures

·Error - error messages

·Fatal - very serious errors

System exception

Exceptions thrown by the system (optional)

Table 1: Data stored in a log entry

Log source | Description
SmartClient | A very general log source for most things logged by the Smart Client

Table 2: Log message sources used by the Smart Client


Application Server connections

Last edited: 10/5/2017 11:51:04 AM

The Application Server Connections defined in the Smart Client are persisted in an XML file. This file contains all the information you entered in the connection settings window, passwords are encoded in an encrypted format.

The connection settings file is located in the roaming application data directory and named ApplicationServerConnectionSettings.xml. If this file is deleted all the Application Server Connections defined by the current user are gone. The next time the user starts the Smart Client he will have to define new Application Server connections.

For system administrators who want to provide their users with some default Application Server Connections the first time they start the Smart Client Redbex provides the possibility to store a ApplicationServerConnectionSettings.xml file in the common application data directory. When the Smart Client start and it cannot find a ApplicationServerConnectionSettings.xml file in the roaming application data directory it will search the common application data directory for this file and if found will copy the file to the user's roaming application data directory.


%Text%

Navigation: Smart Client > Administration >

Smart Client common configuration

Last edited: 10/5/2017 11:51:40 AM

The Smart Client Common Configuration can be used to configure the Smart Client for all users on a computer (contrary to the Smart Client Settings that are stored for each user separately and may be distributed over several computers using Window's roaming user profiles).

The Smart Client Common Configuration can only be modified by editing an XML file and are intended to be used in IT-environments with central deployment strategy. Listing 1 shows an example of an Smart Client Common Configuration XML file; table 1 explains the elements supported in this XML file.

When starting up the Smart Client will search the directories listed in Table 2 for a file named SmartClientCommonConfiguration.xml. Directories are searched in the same order as shown in the table. The first found file found will then be used by the Smart Client. If no file is found or the file found cannot be parsed (XML invalid, file not readable etc) the Smart Client will continue without loading the file.

Details about loading the Smart Client Common Settings are logged.

<?xml version="1.0" encoding="utf-8" ?>
<SmartClientCommonConfiguration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<EnableDownloadingNewVersions>false</EnableDownloadingNewVersions>
<HttpProxyUse>true</HttpProxyUse>
<HttpProxyServer>myproxyserver.local</HttpProxyServer>
<HttpProxyPort>8080</HttpProxyPort>
<HttpProxyUser></HttpProxyUser>
<HttpProxyPassword></HttpProxyPassword>
<HttpProxyBypassLocal>true</HttpProxyBypassLocal>
<HttpProxyBypassAddresses>.*\.local</HttpProxyBypassAddresses>
<FileDepotUploadInitialDirectory>U:\</FileDepotUploadInitialDirectory>
<FileDepotUploadCustomPlaces>
<string>O:\ProjectData\Current</string>
<string>O:\ProjectData\Archive\3BX23</string>
</FileDepotUploadCustomPlaces>
</SmartClientCommonConfiguration>

Listing 1: Example SmartClientCommonSettings.xml file

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="unqualified" elementFormDefault="qualified">
<xsd:element name="SmartClientCommonConfiguration">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="EnableDownloadingNewVersions" type="xsd:boolean" />
<xsd:element name="HttpProxyUse" type="xsd:boolean" />
<xsd:element name="HttpProxyServer" type="xsd:string" />
<xsd:element name="HttpProxyPort" type="xsd:unsignedShort" />
<xsd:element name="HttpProxyUser" />
<xsd:element name="HttpProxyPassword" />
<xsd:element name="HttpProxyBypassLocal" type="xsd:boolean" />
<xsd:element name="HttpProxyBypassAddresses" type="xsd:string" />
<xsd:element name="FileDepotUploadInitialDirectory" type="xsd:string" />
<xsd:element name="FileDepotUploadCustomPlaces">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" name="string" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xs:schema>

Listing 2: Schema for the SmartClientCommonSettings.xml file

Setting | Description
EnableDownloadingNewVersions | Default: true When a Smart Client cannot connect to an Application Server because of a version mismatch it will by default offer the user the possibility to download a suitable version of this Smart Client. Setting this Element to false will disable this behavior.
HttpProxyOverride | Default: false If set the Smart Client will try to use the HTTP proxy configuration as defined in this file. See chapter Smart Client HTTP Proxy configuration for more details
HttpProxyServer | Address of the proxy server (DNS name or IP address)
HttpProxyPort | Port on which the proxy server listens to connection requests.
HttpProxyUserName | Username used to connect with the proxy server. Leave this empty if your proxy server does not need authentication.
HttpProxyPassword | Password used to connect with the proxy server. Leave this empty if your proxy server does not need authentication.
HttpProxyBypassLocal | If set, requests to local Internet resources do not use the proxy server. Local requests are identified by the lack of a period (.) in the URI, as in http://webserver/, or access the local server, including http://localhost, http://loopback, or http://127.0.0.1. If not set, all Internet requests are made through the proxy server.
HttpProxyBypassAddresses | A semicolon separated list of regular expressions that describe URIs that do not use the proxy server when accessed.
FileDepotUploadInitialDirectory | Defines the directory that will be the initial directory when selecting files to be uploaded to the File Depot. Will only be used if the given value is referring to an existing directory.
FileDepotUploadCustomPlaces | A list of directories that will be shown as custom places in the open file dialogue when selecting files to be uploaded to the Filedepot. Only those elements in the list will be used that are referring to existing directories.

Table 1: Supported settings in SmartClientCommonConfiguration.xml

Location

Description.

Application directory

Directory where the executable of the Redbex Smart Client is located. Note that different editions of the Smart Client (Full, Light and Portable) are usually installed in different directories. Therefore it is possible to have different Smart Client Common settings for different editions.

Typical installation directories for the Smart Client (can be different for your installation)

Full: C:\Program Files\Redbex\Smart Client\

Light: C:\Users\<username>\AppData\Local\Redbex\Smart Client\Light\

Portable: C:\Users\<username>\AppData\Local\Redbex\Smart Client\Portable\<Smart Client Light Version>\

Common Application Data directory

The common application data directory for the Redbex Smart Client is a sub directory of Window's Common Application Data folder (typically C:\ProgramData\, but might be different depending on the configuration of the operating system, and the operating system language)

Example

c:\ProgramData\Redbex\Smart Client\

Table 2: Locations in which the Smart Client searches for SmartClientCommonSettings.xml file


%Text%

Navigation: Smart Client > Administration >

Smart Client HTTP Proxy configuration

Last edited: 10/5/2017 11:51:42 AM

The Smart Client connects to the Redbex Application Server using Web Services i.e. using the HTTP protocol. Additionally the Smart Client accesses other HTTP web resources directly i.e. not via the Application Server - see table 1 for a listing of all resources that are connected by the Smart Client directly.

Depending on the network environment in which the Smart Client is installed it might be necessary to configure an HTTP Proxy server to be able to connect all the Web Resources shown in Table 1.

When the Smart Client is started it first checks if there is a specific HTTP proxy server configured in the Smart Client Settings, i.e. if the Smart Client Setting Override system default proxy is set to true. If so the Smart Client will use the HTTP proxy as defined in the Smart Client Settings. If the Smart Client setting Override system default proxy is set to true and the Proxy server is empty the Smart Client will try to connect to the internet without using a proxy server.

If the Smart Client Setting Override system default proxy is not set to true Smart Client will next check if there is an HTTP Proxy configured in the Smart Client Common Settings, i.e. if a Smart CLient Common Settings XML file exists and Smart Client Common Setting HttpProxyOverride is set to true. If so the Smart Client will use the HTTP proxy as defined in the Smart Client Common Settings. If the Smart Client Common setting HttpProxyOverride is set to true and the Smart Client Common Setting HttpProxyServer is empty the Smart Client will try to connect to the internet without using a proxy server.

If neither the Smart Client Settings nor the Smart Client Common Settings define a specific proxy to be used the Smart Client will use the same proxy configuration as defined by the Windows Operating system (Internet Settings).

The HTTP proxy server to be used is evaluated on start up of the Smart Client. Changes to proxy related settings therefore only take effect after a restart of the Smart Client.

The actually used Proxy is logged in the Smart Client log.

Resource | Description
Application Server | Connection to the Redbex Application Server
Distribution Server | Connection to the Redbex Distribution Server is needed for downloading and installing updates.
Google Maps | When rendering a map view with a Google Maps layer the tiles for the Google Maps layer are loaded directly from Google's servers.
Bing Maps | When rendering a map view with a Bing Maps layer the tiles for the Google Maps layer are loaded directly from Microsoft's servers.
Open Street Maps | When rendering a map view with an Open Street Maps layer the tiles for the Google Maps layer are loaded directly from OpenStreetMap servers.
WMS | When rendering a map view with a WMS layer the tiles for this layer will be directly loaded from the specified WMS.
WFS | When rendering a map view with a WFS layer the data for this layer will be directly loaded from the specified WFS.
RSS Feeds | Some widgets available for the Start window show RSS feeds. These feeds are loaded directly from the respective source.
WMS Configuration | When configuring a WMS layer the Capabilities of the WMS are loaded directly from the given WMS.
WFS Configuration | When configuring a WFS layer the Capabilities of the WFS are loaded directly from the given WFS.

Table 1: HTTP Web Resources used by the Smart Client.


Resetting windows layout

Last edited: 10/5/2017 11:51:34 AM

The Smart Client remembers the opened tool windows and the layout of those opened tool windows when the Smart Client shuts down. Therefore the Smart Client is able to restore the last opened windows and their layout on start up.

If you want to return to the default windows layout i.e. the layout that was presented when you first started the Smart Client after installation you can do so by going to the Backstage Menu's Smart Client Administration Section and select Reset windows layout. After acknowledging a confirmation message layout will be reset to the default.

The windows layout is persisted in a simple XML file located in the roaming application data directory and named PersistedLayout.xml. If you delete this file the Smart Client will copy the default layout XML file from the Program Directory.


Permission caching

Last edited: 10/5/2017 11:51:30 AM

While every request that is sent from the client to the Application Server is always checked for authorization on the Application Server, the Smart Client still queries if the currently logged in user has a specific permission on a specific permission object in order to adapt its user interface. For example an item in a context menu could be disabled if the Smart Client knows that the Application Server request that would result from selecting this item will fail due to missing permissions.

Querying permissions many times before building up parts of the user interface influences the reactivity of the system, therefore the Smart Client uses an internal permission cache. Whenever the Smart Client queries a permission from the Application Server it will store the results of this query in its internal cache. The next time the Smart Client is querying for the same permission he will already get the result from its own cache.

The Smart Client's permission cache is not persisted, i.e. the permission cache will be empty on every start of the Smart Client.

Of course this permission cache on the Smart Client will have wrong information as soon as an already cached permission is changed on the Application Server. This can have two effects:

·Parts of the user interface are disabled even though the user was granted the permission to access the Application Server service after the permission was first queried by the Smart Client

·Parts of the user interface are enabled even though the user's permission to access the Application Server service was removed after the permission was first queried by the Smart Client

When you changing permissions on the Application Server (grant or delete privileges) it might therefore be necessary to restart the Smart Client. Alternatively you can select Clear client side permission cache in the Backstage Menu's Smart Client Administration tab.

Figure 1: Clearing the client side permission cache from the Backstage menu


Smart Client settings

Last edited: 11/8/2017 10:04:52 AM

There are some settings that you can use to tailor the Smart Client to your requirements. These Smart Client Settings are stored in the roaming directory on the Computer where the Smart Client is run and are stored for the currently logged on Windows user. Since there are only few Smart Client Settings a backup of these settings is usually not needed.

Note that after changing some of these settings you need to restart the Smart Client for these settings to take effect.

Setting name

Description

Features per page

Defines the number of features displayed on one page in the Feature Explorer window.

The default value is 100. Choose this value depending on the bandwidth and latency of your connection to the Application Server.

Observations per page

The number of observations displayed on one page in the Feature editor window.

The default value is 250. Choose this value depending on the bandwidth and latency of your connection to the Application Server.

Elements per page

The number of elements (page size) displayed in all windows using paging and not having a specific setting for page size.

The default value is 50. Choose this value depending on the bandwidth and latency of your connection to the Application Server.

Table 1: Paging settings

Setting name | Description
Reference manual format | The help format to use
Reference manual CHM file | Full path of the CHM help file. Set to empty to use default CHM file.
Reference manual CHM file | URL of the HTML help. Set to empty to use default URL

Table 2: Smart Client settings Settings for configuring help. See Configuring help for details.

Setting name | Description
Override system default proxy | If set the Smart Client will use the configured proxy. See Smart Client HTTP Proxy configuration for more details about how the Smart Client determines the actually used HTTP proxy.
Proxy server | Address of the proxy server (DNS name or IP address)
Proxy server Port | Port on which the proxy server listens to connection requests.
Proxy server username | Username used to connect with the proxy server. Leave this empty if your proxy server does not need authentication.
Proxy server password | Password used to connect with the proxy server. Leave this empty if your proxy server does not need authentication.
Bypass proxy on local | If set, requests to local Internet resources do not use the proxy server. Local requests are identified by the lack of a period (.) in the URI, as in http://webserver/, or access the local server, including http://localhost, http://loopback, or http://127.0.0.1. If not set, all Internet requests are made through the proxy server.
Bypass adresses | A semicolon separated list of regular expressions that describe URIs that do not use the proxy server when accessed.

Table 3: Smart Client settings for proxy server. See Smart Client proxy configuration for details.

Setting name

Description

Smart Client culture

The culture used for displaying data on the Smart Client. The culture specifies specify the used interface language, date format and number format.

This setting defaults to the culture set for the operating system, and therefore usually needs not change.

Table 5: Localization settings

Setting name | Description
Hide status bar | If set the Smart Client will not show the status bar. Intended for use if the screen resolution is low but not recommended.
Disable auto-login | If set the Smart Client will not automatically connect to the default Application Server Connection. See chapter Connect to Application Server for details.
Do not show Start Page | By default the Start Page is always shown when the Smart Clients connects to an Application Server. With this setting active the Start Page will not be shown.
Show administration tab | If set the Administration Tab of the Smart Client Ribbon will be shown. This tab will always be shown for the manager user for all other users the tab will only be shown if this option is set.
Sort observations descending | By default Observations in the Feature Editor are shown in ascending order. With this setting the order can be reversed.

Table 5: Miscellaneous settings


Configuring help

Last edited: 10/5/2017 11:51:10 AM

The Smart Client offers different possibilities how to access this Reference Manual. Depending on the chosen help format the access to help can be context sensitive, i.e. the chapter that describes your current working context will be shown when you call help.

Via Smart Client settings you can define what help format is used. Table 1 lists the available help file formats. For each format you can choose the source from where the help is loaded. If the source is not given for the selected help format the Smart Client will use a default source.

Help format | Notes
HTML | Displays the help using the default web browser. The help is loaded from a configurable URL. By default HTML based help will point to a server hosted by Pöyry Infra GmbH. You can however configure the Smart Client to use another URL. Using HTML based help with the default URL guarantees that you have always the latest help.
CHM | Displays a compiled CHM help repository. The CHM file used can be configured, by default a CHM file that is installed along with the Smart Client is used.

Table 1: types of help repositories that can be used as source for context sensitive help on the Smart Client

Smart Client Configuration Setting | Notes
CHM Help file full path | The full path of the CHM file to load. If not given the Smart client will search for the CHM file in its installation directory. Examples: N:\redbex\RedbexReferenceManual.chm \\myserver\doc\RedbexReferenceManual.chm
HTML help url | URL where to find the HTML based Help. Can refer to HTML Help stored locally (or on your local network) as well as HTM based help hosted on a web Server in the Internet. If not given the default URL will point to Pöyry Infra GmbH's Web Server.

Table 2: Configuration file settings for configuration of the context sensitive help on the Smart Client


Versioning

Last edited: 11/8/2017 9:32:30 AM

Over time the Smart Client will be deployed in different versions, new features might be added, bugs removed etc. To distinguish between different versions of the Smart Client each version has a unique version number. Version numbers consist of four components: major, minor, build, and revision e.g. 1.38.16312.16318. All components are integers greater than or equal to 0. The format of the version number is as follows:

<major version>.<minor version>.<build number>.<revision>

The components are used by convention as follows:

·Major: A higher major version number indicates a major rewrite of a product or significant new functionality.

·Minor: If the major version number on two Smart Client versions are the same, but the minor version number is different, this indicates functionality enhancements.

·Build: A difference in build number indicates a new version with no significant new features implemented, but small improvements and bug fixes.

·Revision: A difference in revision number indicates a new version with small changes, mostly bug fixes.

Figure 1: The version of the Smart Client is shown on the Smart Client in the Backstage View

Application Server version compatibility

When the Smart Client connects to the Application Server it first gets the Application Server Version and checks if it supports that version. This is done by comparing the major and minor component of the Application Server version number to a compatibility version number that is hard coded within the Smart Client. If the Smart Client does not support that Application Server version you will not be able to connect.

Depending on your configuration (see also Smart Client common settings) of your Smart Client the Smart Client can automatically try do download a new version whenever it detects an incompatibility with the Application settings.

it will not connect but will try to download a version of the Smart Client that is compatible with the Application Server Version.

Example: If the Application Server compatibility number stored within the Smart Client is 2.3 the Smart client can connect to any Application Server whose version number has major component 2 and minor component 3.


Getting new versions

Last edited: 11/8/2017 9:32:30 AM

As new versions of the Smart Client are published they will be made available through the the Distribution Server. The Smart Client can query the Distribution Server for the latest available versions of the Smart Client. This can be done on the users request and is done whenever the Smart Client tries to connect to an Application Server and it finds that it is not compatible with the Application Server version.

Automatic version check

Whenever the Smart Client tries to connect to an Application Server and finds that it is not compatible with that version of the Application Server it contacts the Distribution Server and asks for a Smart Client Version that would fit this Application Server. It will then offer the user to download this version.

Note that the automatic download of new versions of the smart client can be disabled using the Smart Client common settings.

Manually querying for Smart Client updates

To manually initiate querying for the latest available version go to the Backstage Menu's Smart Client Administration Tab and select Smart Client Update Check. If a new version is available you will be prompted to download the new version. Other output of the update check is written to the Output window.

Note that the Smart Client Update Check will query for the latest available Smart Client version if the check is initiated without being connected to an Application Server. If connected to an Application Server the Smart Client Update Check will query for the latest version of the Smart Client that is compatible with the currently connected Application Server.

Figure 1: Initiating a Smart Client update check from the Backstage View


%Text%

Navigation: Smart Client > Administration >

Translation Support

Last edited: 10/5/2017 11:51:36 AM

During start up the Smart Client loads the multilingual labels shown in the user interface from specially formatted XML files. Translators can modify these XML files to translate or re-translate the Smart Client user interface.

Note that the possibility of modifying these XML files is only meant for translators who work on a translation in collaboration with Redbex. Use caution when modifying the XML files, invalid XML files will cause the Smart Client to crash during start up.

Attention: The XML files will be overwritten with each new installation or update of the Smart Client. Backup your modified files before reinstalling or upgrading the Smart Client.

The XML files used by the Smart Client for loading language specific labels are located in a sub-directory called Themes under the Smart Client application directory. Each language is stored in a separate file, the files for all languages except English are named according to the pattern: Strings.[2-Letter-ISO-Code].xaml . The file with the English translation is named Strings.xaml .

After modifying the XAML files you need to restart the Smart Client in order to see the changed labels.


Before you start

Navigation: »No topics above this level«

MappRover

Last edited: 1/22/2018 9:14:04 AM

MappRover is an iOS based client to the Redbex Application Server that allows a fully digital mapping and documentation process of geo-located characteristics in well defined areas along an axis. It was mainly designed for mapping and documenting geological and geotechnical characteristics during the construction of a tunnel but can also be used for mapping of any kind of geo-located characteristics along an axis.


Introduction

Last edited: 1/22/2018 9:18:08 AM

MappRover is an iOS based user interface to the Redbex Application Server that allows a fully digital mapping and documentation process of geo-located characteristics in well defined areas along an axis. It was mainly designed for mapping and documenting geological and geotechnical characteristics during the construction of a tunnel but can also be used for mapping of any other kind of geo-located characteristics along an axis.

The name MappRover is a portmanteau word formed from Mapping, Application or App and Rover and therefore expresses some of the fundamental characteristics of the app.

How MappRover relates to the Redbex Software System

Redbex MappRover is part of the Redbex Software System, i.e. MappRover cannot work without access to a Redbex Application Server and also relies on the Redbex Smart Client as user interface for configuring the whole system and for data evaluation.

While access to the Redbex Application Server is mandatory MappRover can operate without a continuous network connection to that server so that it is fully operable in places where no network connection is available. This of course implies that Redbex MappRover implements a data synchronization procedure that is used to synchronize data that was modified offline with the data on the Application Server.

For most tasks that users can perform with MappRover they do not need any specific knowledge of the Redbex Software System, however an understanding of some basic concepts can be useful.

Redbex is a very generic software product that can be used for many different expert areas, Redbex therefore uses a very generic terminology for data structures and functions. MappRover on the other hand focuses on a very specific task and therefore also uses a very specific terminology, i.e. the same things may be named differently in both systems.

Changed approach

While MappRover was designed around the traditional process of mapping geological characteristics within a tunnel it is not intended to copy this process in every detail. The additional possibilities but also limitations of the hardware and software environment in which the app runs dictates a slightly changed approach.

Not everything that is possible in the pen and paper approach will be possible in MappRover, but on the other hand MappRover provides features that were not possible with the traditional pen-and-paper approach.


<%TOPICTITLE%>

Navigation: MappRover >

First steps

Last edited: 1/22/2018 9:29:08 AM

The next chapters will guide you through your first steps with Redbex MappRover and will help you to accomplish your first mapping event documentation.

Before you start

Before you start please make sure that:

·you have the latest version of MappRover installed on your tablet device.

·you have the connection data to access the Redbex Application Server (this is: server address, server port and instance name)

·you have the login data to authenticate against the Redbex Application Server (this is username and password)

·your tablet device has network connection (preferably a fast WLAN connection). Note that during the first steps with your MappRover a lot of data may be downloaded from the Application Server!

Who can help?

If you need assistance please contact you local support or the Redbex Support at:

Support for Redbex is available from:

Webpage : www.redbex.com

Email: support@redbex.com


First start of MappRover

Last edited: 3/8/2018 7:30:14 AM

When you first start the Redbex MappRover the iOS (operating system of the tablet device) will show an Alert asking you if you want to allow the MappRover to send you Notifications.

MappRover uses iOS Notifications to communicate with the user it is therefore highly recommended to allow notifications by selecting Allow on this Alert. You can change your decision at any time using the the iOS Settings App.

Figure 1: The iOS Alert asking you to allow notifications

If you allowed notifications and your tablet device has connection to the internet you will soon see a first notification telling you that MappRover downloaded the help files successful.

Figure 2: The iOS Notification with information about successful download of the help files


Creating a connection

Last edited: 1/22/2018 9:35:26 AM

Before you start

·Make sure you have an network connection

·Make sure you have the connection parameters to connect to the Redbex Application Server (see below for more details). Ask your administrator if you do not have them.

If MappRover was not configured before (by another user or by your administrator) you will first have to define how MappRover can access the Redbex Application Server that provides the data back-end to MappRover.

When starting the App for the first time you will therefore be shown a dialogue that invites you to create a new connection. Select Create a server connection and you will be taken to the Connection details page where you can input the parameters for the new connection.

Figure 1: Dialogue shown on the login page if no connection is set up.

Providing connection parameters

The parameters for the connection will be given to you by your Redbex Administrator. After all parameters have been defined select the OK button (figure 2:1) on the right of the Navigation bar.

Now MappRover will try to contact the server to make sure if the connection parameters are correct. If it does not succeed you will be presented a message and you can try to correct your connection parameters. If the test is successful you will be taken back to the Login Page.

Figure 2: The connection details for the new connection.

Connection parameter | Description
Name | This is the name for your connection. You may choose any name you want.
Server | This parameter tells MappRover where it can find the Application Server. The address can be given as DNS name like myserver.company.com or as an IP address like 210.134.29.12 or as just the hostname like Server001
Port | The port on which the Application Server is providing its HTTPS services. This is by default set to 443.
Instance | Name of the instance of the Application Server.

Table 1: Parameters of a connection


Logging in

Last edited: 1/22/2018 9:18:08 AM

After starting the Redbex MappRover App you are first taken to the login page.

Why is login necessary?

Redbex MappRover is part of the Redbex Software System which is designed as a multi-user system with a mighty authorization engine. MappRover is designed in a way that allows different users to share a tablet device but still connecting to the Redbex Application Server as different users.

Therefore it is necessary that you identify yourself with a username and password on every start of the MappRover .

Do you have a defined connection to a Redbex Application Server?

Before you can login you have to have a active connection (i.e. MappRover must know how to contact the Redbex Application Server). If this connection has not been defined before (by an administrator or by another user on the same tablet) MappRover will tell you that you have to create a connection first (see previous step for more details).

If a connection is already defined you are presented the login page where you can input username and password. The name of the connection is shown on top of this dialogue (figure 1:1)

Figure 1: Dialogue asking for user name and password

Username and password

The username and password you use to authenticate yourself against the Redbex System will be given to you by the Administrator of the Redbex system. If the Redbex Application Server is connected to an Active directory the username and password will be your Domain user and Domain password.

Enter username and password and select Log in (figure 1:2)

Note: When logging in with a specific username for the first time you have to have a connection to the Redbex Application Server to be able to authenticate. The authentication data will then be cached, so that for future logins with the same username you do not have to have a connection to the server

Automatic logout

MappRover will automatically log you out after more than 30 minutes of inactivity.


Configuring workspaces

Last edited: 3/8/2018 7:30:14 AM

After successfully logging in to the application you are taken to the Workspaces page. Workspaces are containers for construction areas, just like folders are a container for files in a file system. This page shows the workspaces available to you.

If you start MappRover for the first time and if the application has connection to the Redbex Application Server it will fetch the list of available workspaces from that Application Server automatically.

Tip: If you want to refresh the list of available workspaces at a later point in time you can do so by swiping down the workspaces list while having network access to the Redbex Application Server.

Workspaces are created and managed on the Redbex Application Server through the Redbex Smart Client, you cannot create or modify workspaces within MappRover.

Activating or deactivating synchronization for a workspace

The workspaces listed on this page are the workspaces that are available for you. To get all the data (contained construction areas and their mapping events) in a workspace you have to first enable synchronization for the workspaces and then you have to start the synchronization process.

To activate or deactivate synchronization for a specific workspace tap on the on/off button for synchronization of a workspace (see figure 1)

Figure 1: Enabling synchronization for a workspace

Note: This only activates synchronization for workspaces, the actual synchronization has to be started manually.


Synchronizing data

Last edited: 3/8/2018 7:30:14 AM

MappRover works with a locally stored data and synchronizes this data from with the Redbex Application Server whenever the user chooses so. This way MappRover is fully functional in situations when no network connection is available (after an initial synchronization of course).

After you have enabled synchronization for at least one workspace (see previous step) open the synchronization dialogue from the Workspaces page's navigation bar (see figure 1:1).

Figure 1: Opening the synchronization dialogue from the navigation bar of the workspaces page.

Figure 2: The synchronization dialogue

Make sure that you have internet connection. and select Start synchronization on this dialogue (figure 1:1). After this the actual synchronization of data will start and MappRover will show the progress of the synchronization in this dialogue.

Note: Synchronization might take a long time when you first synchronize a workspace, since all the data (including pictures etc) for the workspaces where synchronization is enabled has to be downloaded to the tablet. For the first synchronization we therefore suggest you are connected to the Internet with a fast WLAN or LTE connection. Subsequent synchronizations will be a lot faster since only the difference will be synchronized.

You may break the synchronization at any time, and the application also will handle lost server connections during synchronization. However we suggest to wait till the synchronization finished successfully.

Figure 3: Synchronization progress

Figure 4: End of synchronization


Selecting a construction area

Last edited: 3/8/2018 7:30:14 AM

When selecting a workspace on the Workspaces page you will be taken to the Construction areas page that lists all Construction areas within the currently active workspace.

In this list simply tap on the construction area you want to work with to open the Mapping page for this construction area.

Note: The list of construction areas is empty if the Workspace either does not contain any construction areas or if the workspace was never synchronized before.


Mapping

Last edited: 3/8/2018 7:30:14 AM

After selecting a construction area MappRover shows the map for this construction area on the Mapping page. The mapping page is a GIS like 2D representation of the construction area that allows you to view and modify mapping events and mapping objects.

For an explanation of the main elements on this page please see the documentation for the mapping page.

If the construction area already contains mapping events the map will automatically set the detail area around the latest mapping event, else the map will zoom to the full extents of the construction area and will not automatically set a detail area.

Figure 1


Setting the mapping area

Last edited: 3/8/2018 7:30:14 AM

For performance reasons the map will not show mapping objects of all mapping events in a construction area but only for those mapping events that are in a mapping area you selected. The grid, chainage labels and other visual elements will also only be shown for the detail area and you can create new mapping events only within the geographic region of the detail area.

When opening the mapping page for a construction area that has mapping events the detail area will be automatically set around the latest mapping event. When opening the mapping page for an empty construction area MappRover will not automatically set a detail area.

Setting the mapping area

You select a detail area simply by tapping in. When you have tapped it, the borders of the mapping area becomes purple as seen in Figure 1. A new menu bar also appears in the top. In that menu bar you can

1.Activate area

2.Change area

3.?

4.Delete

Figure 1 New menu bar for mapping areas

Changing the detail area

If you want to set another part of the construction area as your detail area just repeat the above described procedure. Note that you cannot change the detail area as long as you have an active mapping event.

Figure2 Selecting a mapping area


Creating mapping events

Last edited: 3/8/2018 7:30:14 AM

To create a new mapping event first make sure that you have set a mapping area and that you do not have an active mapping event. In this case the primary toolbar will show the Mapping event tool.

The mapping event tool provides 3 different modes that can be used to draw the polygon that geometrically defines the boundaries of the mapping event.

Freehand

Point by point

Axis from-to


Defining mapping event attributes

Last edited: 3/8/2018 7:30:14 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Activating a mapping event

Last edited: 3/8/2018 7:30:14 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Creating mapping objects

Last edited: 10/5/2017 11:51:12 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Working with layers

Last edited: 10/5/2017 11:51:46 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Further reading

Last edited: 10/5/2017 11:51:20 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


User's guide

Last edited: 1/22/2018 9:14:04 AM

Following chapters will give you in-depth information on how to use MappRover.


Basic information

Last edited: 10/5/2017 11:51:06 AM

Following chapters shall give you the


User interface basics

Last edited: 3/8/2018 7:30:14 AM

Navigation bar

Gestures

Swipe


User isolation

Last edited: 10/5/2017 11:51:44 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Structuring data

Last edited: 1/22/2018 9:14:04 AM

Whenever we store data in a computer system we have to think about the structure in which the data is stored. This data structure then dictates what data can be stored and also how easy it is to evaluate the data once it has been recorded.

MappRover defines a basic data structure that consist of four elements

1.Workspaces: A workspace is a simple collection of construction parts and helps to organize construction parts into groups. It is also the smallest unit that can be synchronized.

2.Construction areas: A construction area is a representation of a real world construction area. It is defined by it's own axis reference system and mapping template

3.Mapping events: A spatial region on the mapping template of a construction part that was subject to the mapping at a specific point in time.

4.Mapping objects: An object mapped as part of a mapping event. A mapping object has a specific type that defines its attributes. Each mapping object has a geometrical shape.

Especially in geology and geotechnics the data that we document is very much depending on the location, contractual obligations, etc. A construction part in MappRover has therefore an underlying type. That type defines what attributes are available to describe the mapping event, which mapping object types are available and which attributes are available fore each of these mapping object types.


Basic navigation in the applicaiton

Last edited: 3/8/2018 7:30:14 AM


App vs. Desktop Software

Last edited: 10/5/2017 11:51:44 AM

Software designed for tablet devices (aka Apps) have to stick to software design principles that are different from those for software for desktop PCs.

Device specific

·Smaller screen

·Slower processor

·Limited memory and storage space (cannot be upgraded)

Network

·Less bandwidth,

·Not always connected

·Different networks (security!)

Device interaction

·Touch, Pen input

·No hover events

·Less precision

·Gestures

·Tricky keyboard

·Variable screen orientation

Usage scenarios

·Walking around, inside or outside

·Sitting on a desk

·Discussing with other people

Two buzzwords

·Consumerization: Simple Installation and update, Simple usage.

·Compartmentalization: Mobile apps function to accomplish a specific task or set. Compartmentalization yields simplicity.


iOS UI

Last edited: 10/5/2017 11:51:26 AM

Standard UI Elements

·Navigation bar + Pages

·Status bar

Gestures

·Tap

·Long tap

·Double tap

·Pinch

·Drag

·Swipe Down

·Swipe left right


Localization

Last edited: 3/8/2018 7:30:14 AM

The MappRover is designed to adapt to the linguistic, cultural and technical requirements of your locale, this includes especially:

·The language texts displayed on the user interface

·The display and entry of date & time values

·The display and entry of numerical values

When MappRover starts it will read, the Language % Region settings of you device.

Setting the culture iPad

Check if main language is supported else switch to English.

If Main language is not supported we will switch secondary language else to English.


Technological basics

Last edited: 3/8/2018 7:30:14 AM

Device support

MappRover is currently supporting iPad Pro 12.9" devices with iOS 10.2. However MappRover but was designed in a way that it can be ported to other devices and other operating systems in future.

Basics for digital mapping

One of the main parts of the documentation process is the mapping i.e. sketching the shape of some real-world object on the user interface of MappRover.

When it comes to drawing or sketching with computer systems there are several different paradigms that can be used.

CAD-like construction: Drawing is constructed with high precision.

Pixel-based painting: Close to artistic painting.

Vector based drawing: like Adobe InDesign.

GIS-like drawing: GIS-like drawing uses a limited set of possible geometric shapes and enforces parameter-based (implicit) styling.

For several reasons MappRover uses the GIS-like approach

·No artistic painting support (shading, pressure-depended line thicknesses etc)

·No CAD-like precision, no construction tools - but tools for freehand sketching

·No explicit styling but implicit styling through attributes and styling rules

Single user device - multiuser concept

The tablet operating system is a single user operating system. Redbex however tries to enforce strict separation between users.


Connections and Login

Last edited: 3/8/2018 7:30:14 AM

The following chaptes gives you an overview over hos connections, login, automatic logout and version compatibility of MappRover.


Connections

Last edited: 1/22/2018 9:14:04 AM

A connection is a stored set of parameters that define how MappRover can access a Application Server.

In MappRover you can define any number of connections. However before login you decide with which connection you want to work by picking one of the defined connections as the active connection. MappRover will always only work with one connection at one time.

When creating a new connection in MappRover the device must have network access to that Application Server. Only if MappRover can verify the validity of the given connection parameters you will be able to store the connection.

In MappRover connections are defined independent of the user (since have to be defined before a user logs in). I.e. all created connections can be seen and modified by any tablet user.

When a connection is deleted the data that is locally stored for that connection will not be deleted immediately. Therefore if you recreate a connection with the same connection settings, the data for that connection will be available again.

Internally a connection is identified by a unique connection ID provided by the Application Server. You can only create one connection to one specific Application Server instance.

Parameter | Description
Name | A descriptive name for the connection.
Server | The address of the server can be specified using host-name / domain-name or IP-Address. Examples: ·myserver.mydomain.com ·110.171.1.34 ·myserver
Port | The port on which the server provides its services via HTTPS. Default: 443 Note: The MappRover accesses the Redbex Application Server only via HTTPS.
Instance | Instance name of the Redbex Application Server e.g. Instance01

Table 1: Connection parameters


Login

Last edited: 3/8/2018 7:30:14 AM

On every start of the application and after a manual or after automatic logout the user has to provide username and password to log into the application before the application can be used.

If the tablet device has network connection and the application can reach the Redbex Application Server defined in the current connection it will ask the server to validate the given username and password. If this validation is successful the application will store the username and password locally (and encrypted) so that the next login can also be done without connection to the Application Server.

Therefore it is not possible to log into the application with a username that has never been used for a successful login before. I.e. for the first-time login of a user the application has to have connection the the Redbex Application Server.

If the login fails for some reason this reason is shown to the user. See table 1 and table 2 for possible login failure reasons.

Failure | Reason
Username / password wrong | Either username or password is wrong, i.e. does not match the username and password stored on the Redbex Application Server (or in the Active Directory used by the Application Server.

Table 1: Reasons for login failure when Application Server is reachable.

Failure | Reason
Username / password wrong | Either username or password is wrong, i.e. does not match the username and password locally stored on the device.
Credentials not cached | The user never logged in before from this device. Therefore the device does not have a cached password for this user.

Table 2: Reasons for login failure when Application Server is not reachable.


Automatic logout

Last edited: 1/22/2018 9:14:04 AM

For security reasons MappRover implements automatic logout, i.e. after 30 minutes of inactivity the application will automatically end your session and you have to re-login.

Inactivity is when

·MappRover is not the foreground (currently active) application on your device

·Your tablet device is locked


Version compatibility

Navigation: MappRover > User's guide > Connections and Login >

Authentication

Last edited: 1/22/2018 9:14:04 AM

The MappRover will only be able to connect to the Redbex Application Server if the version number of the application is compatible with the version number of the Application Server.


Pages

Last edited: 3/8/2018 7:30:14 AM

As in many other iOS applications the navigation within MappRover is built around the concept of pages. Table 1 summarizes the pages used in MappRover, in the following chapters each of these pages is described in more detail. Figure 1 gives you a hierarchical overview of the pages, and how to navigate between them.

Page name | Notes
Login | This page is always displayed after starting the App.
Connection management | This page can be reached from the Login page and allows you to define connections to one or more Redbex Application Servers.
Workspaces | This page will be automatically shown once you have logged in. The page lists the workspaces available to the currently logged in user, and can synchronizes workspaces with the Redbex Application Server.
Construction areas | Lists the construction areas available within a selected workspace.
Mapping | On this page you can view and edit mapping events for the selected construction area.
Synchronization | This page can be called from the Workspaces page. It is used to synchronize data with the Redbex Application Server defined by the current connection.
Personal settings | This page is accessible from most other pages through a button on the navigation bar. The page shows some settings that influence the look-and feel of the application. These settings are stored for the currently logged in user.
Help | This page is accessible from most other pages through a button on the navigation bar. The help

Table 1: Overview of pages

Figure 1: Pages overview


Login

Last edited: 3/8/2018 7:30:14 AM

When you start the MappRover you will first need to log-in. For this you have to select a connection and provide username and password. Username and password will be validated against the Redbex Application Server defined with the selected connection.

When logging in with a username that has not logged in before the device has to have a network connection to the Redbex Application Server. After a user has successfully logged in the password (i.e. a hash of the password) will be cached locally so that future log-in attempts with the same user name can be validated without a network connection.

The MappRover is designed to support device sharing, i.e. it supports a scenario where multiple users share a single tablet device. Therefore username and password have to be provided on each start of the application.

Selecting the connection

The current connection is shown on top of the login dialogue if you want to change the active connection select Change connection link on the login screen to open the connection management page where you can define the current connection by tapping on it. You will then be taken back to the login screen.

For more information on managing connections see chapter Connection management.

Note: If no connection is defined yet (or if all connections in the connection management were deleted) the login page will not show the input fields for username and password, but will just show a hint that before login you have to create and select a connection.

Selecting a recently logged in user

To limit the amount of typing you have to do on the login page MappRover remembers the names of the users that have once logged in to the application. When setting focus on the username text field the a picker with a list of recently logged in users will appear and you can quickly pick one of these.

Logging in

After username and password have been entered you can log in by either selecting the login button or by hitting the enter key on the virtual keyboard.

Note: MappRover intentionally provides no way for storing a user's password


Connection management

Last edited: 1/22/2018 9:14:06 AM

MappRover needs a Application Server as backend. Therefore it is necessary that you define the necessary parameters to access a Redbex Application Server from within MappRover before you can login to MappRover.

Note: MappRover allows you to define any number of connections to different Redbex Application Servers. However only one connection can be active at a specific time, i.e. you will always work with one specific Redbex Application Server at one time.

Opening connection management

The Connection management page is accessible from the Login page by selecting the Change connection link. Note that if there is no connection defined yet the application will directly automatically take you to the Connection page and not to the connection management page.

Adding a new connection

To add a new connection select the + Button in the navigation bar. This will bring up a Connection page where you can define all the necessary parameters for a connection. Table 1 shows the properties you have to define for a connection

Connection parameter | Description
Name | This is the name for your connection. You may choose any name you want.
Server | This parameter tells MappRover where it can find the Application Server. The address can be given as DNS name like myserver.company.com or as an IP address like 210.134.29.12 or as just the hostname like Server001
Port | The port on which the Application Server is providing its HTTPS services. This is by default set to 443.
Instance | Name of the instance of the Application Server.

Table 1: Properties for a connection

Deleting a connection

To delete an existing connection swipe from right to left on the connection element in the list and select Delete

Editing a connection

To edit an existing connection swipe from right to left on the connection element and choose Edit


Workspaces

Last edited: 3/8/2018 7:30:14 AM

The workspaces page lists workspaces that are available for the currently logged in user. A workspace is a container for construction areas, just like a folder is a container for files in a file system. Workspaces are created and managed on the Redbex Application Server. MappRover will only show those workspaces for which the currently logged in user has the appropriate permissions.

Figure 1: The workspaces page

Update workspace list from Application Server

The list of available workspaces is synchronized with the Redbex Application Server separately (i.e. not as part of the construction area synchronization). When opening the workspaces page for the first time and if a connection to the Application Server can be established, MappRover will automatically try to fetch the list of available workspaces from the Application Server.

After that any subsequent for the workspace list have to be initiated by the user by swiping down the workspaces list, while having network access to the Application Server. While updating the list of workspaces a progress indicator will be shown. After update is complete the list of workspaces will be refreshed and newly added workspaces will be shown.

Note: Updating the list of workspaces does not download or synchronize any data of the construction areas that are within a workspace.

Enabling / disabling synchronization for workspaces

For every workspace you can decide whether the data in this workspace (construction ares, mapping events, etc) shall be synchronized with the Application Server or not. To enable synchronization for a workspace use the synchronization switch shown for each workspace in the list (see figure 1:1). If a workspace is marked as not to be synchronized it will not be deleted.

We recommend that you enable synchronization only for those workspaces that your are really working on. Consider that:

·The more workspaces are enabled for synchronization the more time the synchronization process will take

·The more workspaces are enabled for synchronization the more storage spaces is used on the tablet device (and remember that all users working with the same tablet share the limited storage space)

Last synchronization and last local change date

Every workspace entry in the list of workspaces shows when it was last synchronized with the Application Server (see figure 1:2).

Selecting a workspace

To select a workspace and show all the construction areas within this workspace just tab the workspace in the list.


Construction areas

Last edited: 3/8/2018 7:30:14 AM

The Construction areas page lists the construction areas that are members of the currently selected Workspace.

Each element in this list shows following information:

Name of the construction area: The name of the construction area (name of the corresponding feature on the Redbex Application Server)

Last synchronization: Shows how long ago this construction area was last synchronized with the Redbex Application Server.

Last local change: Shows when the the last local change to this construction area was made. I.e. how long ago the current user made the last change to a mapping event or a mapping object on the tablet device.

Figure 1 Construction areas with their last synchronization date and last local change date


Mapping

Last edited: 3/8/2018 7:30:14 AM

The mapping page is a GIS like 2D representation of the construction area that allows you to view and modify mapping events and mapping objects.

Main user interface elements of the mapping page

Navigation bar

The iOS navigation bar on this page contains some important command buttons

1: The Construction areas navigation link brings you back to the construction areas page.

2: Layers: Tapping this button will show the layers toggle window (and will automatically hide any other currently opened toggle window). The layers window allows you to define which information shall be visible on the map and which information shall be hidden.

3: Pictures: Tapping this button will show the pictures toggle window (and will automatically hide any other currently opened toggle window). The pictures window allows you to take pictures with your tablet device and store it with a reference to the currently selected mapping event or mapping object.

4: Attributes: Tapping this button will show the Attributes toggle window (and will automatically hide any other currently opened toggle window). The attributes is used for displaying and modifying the attributes for the currently selected mapping event or mapping object.

5: Help: Tapping this button will open the help topic for this page

6: Information pop-up: Tapping this button will open the information pop-up and your personal setting

Zoom buttons

The zoom buttons can be used to zoom in or zoom out. Alternatively you may also use a pinch gesture for zooming.

North Arrow

The North Arrow on the left lower edge of the mapping page shows the orientation of the map. Note the orientation of the map changes according to the selected detail area or active mapping event. When zooming to the extents of a construction area the Map will always be rotated so that North is in 12 o'clock direction.

Status bar

The status bar on the bottom edge of the mapping page will show some status information

Scale

The scale bar allows you to estimate the scale currently used on the map i.e. it allows you to estimate the size of objects.

Primary toolbar

The primary toolbar on the left side of the mapping page is used to choose the tool you want to work with. The first command button on this toolbar is always the Selection tool. All other command buttons on this toolbar depend on the context.

Secondary toolbar

The secondary toolbar appears for tools selected in the primary toolbar if the selected tool supports additional tool options.

Action bar

If a mapping object or a mapping event is selected an action bar will appear just below the Navigation bar. This action bar allows you to start actions on the selected objects.

Figure: Action bar as shown for a selected mapping object with a line geometry, allowing geometry inversion.

Finalization buttons

Some actions you perform on the mapping page must be explicitly finalized or canceled. In this case finalize buttons are shown. Finalize buttons can have different meanings in different contexts. The label on these buttons will clearly state what will happen if you tap this button in the current context.

Long-tap-menu

When you long tap on the map the mapping page will show a long tap menu. Depending on the context in which you are (i.e. if you have a detail area set or not) the menu will provide different options.

On top of the menu you will see the coordinates and the chainage at which you long-tapped to open the long tap menu. Below this you will see the available menu options.

Set detail area: Only available if there is no active mapping event. Will set the detail area around the tapped position.

Zoom to active mapping event: Only available if a mapping event is active. This will take you to the currently active mapping event and will zoom the map so that you see the extents of this mapping event.

Zoom to extents: Zooms to the extents of the whole construction area, and rotates the map so that North is at 12 o'clock.

Cancel: Close the menu

Gestures

Following gestures are available on the map when the Selection tool is chosen:

·Pinch zoom: Zoom in and out

·Swipe Pan: Tap and swipe to navigate on the map

·Long tap: Open up the Long-tap-menu

Note when drawing or editing a mapping object or mapping event these gestures are not available.


Primary Toolbar

Last edited: 3/8/2018 7:30:14 AM

The primary tool bar is used for selecting the action that you want to perform on the map. The tools shown on this toolbar depend on the current context of the mapping page.

·If no detail area is set the only tool available on the primary tool bar is the Selection tool

·If a detail area is set but no mapping event is currently active the Selection tool and the Mapping Event tool are available.

·If a mapping event is activated one tool is available for every mapping object type supported by the currently loaded construction area.

To allow the display of a bigger number of mapping object tools in the primary tool bar the tools may be separated into pages. You can flip through pages of tools by tapping on the Toll-set switcher command button on the bottom of the primary toolbar.

The mapping event tool and the mapping object tools can support different types of geometries and different drawing modes. The currently selected geometry and drawing mode will be shown as a small icon on the bottom right corner of the tool. To change the type of geometry and the the drawing mode, long-tap on the tool in the primary toolbar an pop-up menu for the selection of geometry and drawing mode will be shown (see figure 1).

Figure 1: Long-tap on tool

Initiate the creation of new mapping events by selecting the mapping even tool and the way how the mapping event shape shall be drawn.

Initiate the creation of new mapping objects by selecting the type of mapping object you wan to create and the way how the shape of that object shall be drawn.


Grid snapping

Last edited: 3/8/2018 7:30:14 AM

In the center top there's an icon with a magnet and a grid. By clicking this, your drawing "snap to the grid". That means, if you are not clicking exactly at a one meter mark, MappRover will help you snap your drawing to that one meter mark.


Grid

Last edited: 3/8/2018 7:30:14 AM

Geben Sie hier den Text ein.


Setting Focus

Last edited: 3/8/2018 7:30:14 AM

By setting the focus to a specific point on the map MappRover will automatically adjust rotation, view port and scale of the map. The user can initiate setting the focus by long-pressing on a specific position on the map and selecting Set focus in the appearing menu. The position (X, Y coordinates) on which the user long-pressed will the be used as input to the logic that sets the focus.

The actual focus will be determined differently depending on whether the pressed X,Y coordinates are contained within an existing mapping event or are outside of all mapping events.

Not in a mapping event

If the pressed position on the map (X, Y coordinates) are not within an existing mapping event following logic is used to set the focus.

·Get nearest axis point from given coordinates: the nearest orthogonal projection point from the given coordinates to the axis is determined. If no orthogonal projection can be found the focus cannot be set.

·Bearing of the axis at the nearest orthogonal projection point is determined

·Rotation of map view is set so that the tangent of the axis at the nearest orthogonal projection point, points upwards (12 o'clock position)

·The map view is zoomed to a 1:200 scale

·The viewport is set so that the nearest orthogonal projection point is in the center of the screen.

In a mapping event

If the pressed position on the map (X, Y coordinates) is within the boundaries of an existing mapping event following logic is used to set the focus.

·The centroid of the mapping event is determined. The centroid can be thought of as the "center of gravity" the point around which the area contained by the polygon is evenly distributed. The position of the centroid is derived mathematically from a calculation based on the overall shape of the geometry.

·Get the nearest axis point for the centroid: the neares ortogonal projection point from the centroid to the axis is determined. If no orthogonal projection can be found the f

·Get nearest axis point for that center (

·Rotate around nearest axis point (according to bearing of axis)

·Set scaling to 1:200


Taking pictures

Last edited: 3/8/2018 7:30:14 AM

For every mapping event, you can take one or multiple pictures. While having a construction area selected, press the camera to take a picture. The picture will be stored as associated data to the feature. The associated data is possible to view in MappRover.


Working with layers

Last edited: 3/8/2018 7:30:14 AM

Geben Sie hier den Text ein.


Navigation: MappRover > User's guide > Pages > Mapping >

Mapping events

Last edited: 3/8/2018 7:30:14 AM


Personal Settings

Last edited: 3/8/2018 7:30:14 AM

You can edit you personal settings by clicking the person icon in the top right corner, see Figure 1

Figure 1 Top bar

After clicking the icon you are presented with options "Edit personal settings" and "Log out" as seen in Figure 2 .

When you click Edit personal settings you are presented with the screen show in Figure 3.

Figure 2 Edit personal settings | Figure 3 Edit personal settings options


Synchronization

Last edited: 1/22/2018 8:53:28 AM

Redbex MappRover usually works in offline mode, i.e. it does not require to have direct network access to the Redbex Application Server at most times. This allows you to use MappRover in places where no network connection is available.

Data exchange between MappRover and the Redbex Application Server is done via data synchronization. The synchronization process detects data changes within MappRover as well as data changes on the Application Server and uploads or downloads this changed data. As with every data synchronization process there may be conflicts during synchronization (e.g. when the same data was changed in MappRover and on the Application Server since the last synchronization). In this cases the synchronization will ask the user for his input to resolve these conflicts.

MappRover operates on base data that you cannot create within the application but which is only loaded from the Application Server during synchronization, therefore it is necessary to synchronize MappRover with the Application Server at least once before starting to work with MappRover

As a general rule we recommend to synchronize data often (depending on how much data is changed on the Application Server and on the MappRover). This will reduce the number of conflicts and will decrease the time for one synchronization run.

The list of available workspaces and the construction areas within those workspaces (including all mapping events, mapping objects etc.) are implemented as two separate synchronization processes. This enables you to selectively only synchronize data in selected workspaces and therefore save local storage space and minimize synchronization time.


Workspaces list

Last edited: 1/22/2018 9:00:12 AM

The available workspaces are automatically updated after a successful login to MappRover if a network connection is available and if the workspace list has never been updated before. After that you can trigger the workspace synchronization manually by dragging down the list of workspaces on the Workspaces page (while having a network connection).


Construction area synchronization

Last edited: 1/22/2018 9:14:06 AM

The synchronization for construction areas walks through all workspaces that are enabled for synchronization and for each of these workspaces it goes through all the contained construction areas and synchronizes them one by one.

Synchronizing construction areas

First step is the synchronization of construction areas, i.e. the containers for mapping events (features in Redbex). Construction areas are identified by an internal ID that is created by the Redbex Application Server when the feature is created.

·Construction areas that exist on the App and on the Redbex Application Server: no synchronization needed

·Construction areas that do not exist locally but on the server (i.e. new construction areas): Construction area base data is downloaded and new construction areas are created on the App.

·Construction areas that exist on the App but not on the Server, i.e. construction areas where the corresponding feature in Redbex was deleted is not member of the workspace any more: This situation will raise a conflict with following resolution options:

oKeep local construction area: Construction area will be kept locally. On next synchronization this conflict might appear again (except when the corresponding feature on the server is again made available to the workspace)

oDelete local construction area (with all contained data): This will delete the locally stored construction area with all its mapping events and mapping objects (including changes that were never synchronized to the server before.

Construction area content synchronization

For each construction area MappRover synchronizes all basic data and all mapping events.

Update base data

Name, description

The axis reference system used by the construction area is downloaded if any part of the system was changed this includes: Axis reference system, Axis, Mapping templates.

The configuration of the feature type (Observation Property structure, Observation property structure configuration (for in the context of the feature) and Application specific Observation property structure configuration are downloaded and replaced if they were changed on the server.

Mapping events

For each mapping event following synchronization steps are executed:

·Check for mapping events that were once synchronized to the App but are now deleted on server

oIf mapping event was also also deleted locally deleted: no synchronization action needed

oIf mapping event is not not deleted locally then:

§If mapping event was modified locally: raise conflict with following resolution options:

·Delete local: The locally modified event will be deleted

·Restore to Server: the locally modified event will be uploaded to the server.

§If mapping event was not modified locally: local mapping event is deleted without conflict.

·Check locally deleted events

oIf mapping event was deleted locally and was not changed on server in the since the last synchronization that mapping event will be deleted on the server.

oIf a mapping event was deleted locally but was changed on the server since the last synchronization a conflict is raised: Resolution options:

§Restore local data from server: Mapping event is downloaded from the server

§Delete on server: Mapping event is deleted on server

·Check locally created mapping events (since last synchronization)

oAll locally new mapping events will be created on the server.

·Check events existing locally and on server

oIf the locally stored last update date equals the last update data stored on the Application Server no synchronization action is needed.

oIf the date of the last synchronization is less than the date of the last modificaiton of the mapping event on the Application server:

§If the last update of the mapping event is greater than the last synchronization date (mapping event was updated locally since the last synchronization) a conflict is raised:

·Take local

·Take Server

§Else (Changes on server but not local)
Download server version (actually delete local event and get new from server at a later point in time

oElse (no changes on server since last sync)

§Overwrite server with client data

·Get events only existing on server
Download only

Aborting synchronization

Construction area based

Todos and Tests

·If an classification element is deleted on server

·Last update code for server

oAxis, Axis RS, Mappinge Event

oValidation, Feature type configuration

oClassifications

·Try Catches (lost connection)


Mapping

Last edited: 10/5/2017 11:51:28 AM

Geben Sie hier den Text ein.


Navigating on the map

Last edited: 10/5/2017 11:51:30 AM

Whenever the selector tool is enabled you can freely pan the map of a construction area using with pan-gestures. Zooming in or out can be done using the zoom buttons or using zoom-in or zoom-out gestures.

To see the full extents of a construction area (i.e. the whole mapping template and contents of all information layers) you can call the long-tap-menu and select Zoom extents there.


Creating a mapping event

Last edited: 3/8/2018 7:30:14 AM

A mapping event is the area on the mapping template of a construction part that is documented at the same time. In MappRover a mapping event is represented by a polygon geometry and associated attributes.

Mapping events are always disjoint i.e. there is no point on a mapping template that can be covered by more than one mapping event.

By looking at the icon in the bottom right corner, you can see if the mapping object is currently a point, a line or a polygon. There are three types of polygons.

For example Spot bolts is a point, whereas Systematic bolting is a polygon. The polygon can be changed though, by long tapping the icon.

By long clicking icons with a polygon geometry you can change the type geometry for the objects.


Drawing point geometries

Last edited: 3/8/2018 7:30:14 AM

Geben Sie hier den Text ein.


Drawing line geometries

Last edited: 3/8/2018 7:30:14 AM

Geben Sie hier den Text ein.


Drawing polygon geometries

Last edited: 3/8/2018 7:30:14 AM

MappRover provides three different ways to draw a polygon

Freehand polygon

To draw a freehand polygon simply draw the outline of the polygon with finger or pen. MappRover will create a polygon out of the drawn outline by either connecting the ends of the drawn line or by cutting the line at the first intersection and connecting the end of the line afterward.

Point by point polygon

The point-by-point polygon drawing mode is best suited for drawing polygons with long straight segments. Tap on the map at each position of the polygon. Long-Tap to end the polygon drawing.

Axis section polygon


Joining mappig objects

Last edited: 3/8/2018 7:30:14 AM

Geben Sie hier den Text ein.


Splitting mapping objects

Last edited: 3/8/2018 7:30:14 AM

Geben Sie hier den Text ein.


Working with prognosis objects

Last edited: 10/5/2017 11:51:46 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Copying attributes

Last edited: 3/8/2018 7:30:14 AM

Geben Sie hier den Text ein.


Attributes

Last edited: 3/8/2018 7:30:14 AM

Geben Sie hier den Text ein.


Modifying mapping event shapes

Last edited: 3/8/2018 7:30:14 AM

Geben Sie hier den Text ein.


Help files

Last edited: 1/22/2018 9:14:06 AM

The help files for MappRover are not part of the application itself but are downloaded from the Internet. This way you can get the latest version of the help files without having to install a new version of MappRover.

On start of the application MappRover will automatically try to download help files from the Internet, if help files have never been downloaded before.

After that you can download the latest version of the help files by going to the help page and selecting Download help from the navigation bar.

Figure 1: The button in the navigation bar that triggers download and install of the latest help files.

Note for administrators: MappRover tries to download the latest help file from http://www.redbex.com.


Versioning

Last edited: 11/8/2017 9:32:40 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Adminstrator's guide

Last edited: 1/22/2018 9:14:06 AM

Following chapters discuss a few topics concerning the administration of MappRover.


Installation

Last edited: 10/5/2017 11:51:24 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Deinstallation

Last edited: 1/22/2018 9:14:06 AM

To unistall MappRover from your tablet simply follow standard procedure for iOS.

Attention: Any un-synchronized data of any MappRover user will be lost on un-installation of the app!


Settings app

Last edited: 1/22/2018 9:26:22 AM

Redbex MappRover will add its own preference section to the iOS Settings App. The Settings app is an app that is installed on every iOS device by default. It offers access common iOS settings and settings specific to the installed third party apps like MappRover.

Table 1 explains the settings available in the MappRover section of the iOS Setting app.

Setting

Description

Notifications

In this section you can define if MappRover is allowed to send you notifications, and you can define how these notifications will be displayed.

MappRover uses notifications intensively to communicate with the user. We therefore strongly recommend that you allow the app to send you notifications

Clean up data on next execution

If this setting is enabled all data of all users stored by the application on the tablet device will be deleted on next start of the application.

Attention: This will delete all locally stored data. This action cannot be undone!

Version

Shows the version of MappRover

Copyright

Well you know...

Table 1: MappRover settings in the iOS Settings App.


Cleaning up data

Last edited: 10/5/2017 11:51:10 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Administrator's manual

Last edited: 10/5/2017 11:51:02 AM

This part of the Reference Manual includes information usually important for system administrators. It covers installation and low level configuration as well as details for performance optimization and other technical information.


Installation

Last edited: 10/5/2017 11:51:24 AM

Installation is the process of making Redbex ready for use in your IT environment. The n-tier structure of Redbex gives you great flexibility in designing an installation scenario that best fits your requirements, be it a simple single computer installation or a distributed installation integrated in your local IT environment and aiming for highest performance.

This chapter provides the information you need to define your installation scenario, to install and to configure the tiers. Refer to the update section if parts of the system are already installed and you just want to update to a later version.

For a first time installation you should strictly stick to following installation sequence of the tiers:

1. Application Server Database

2.Application Server

3.Smart Client(s)


Installation scenarios

Last edited: 10/5/2017 11:51:24 AM

Being an n-tier system and being built to scale easily from smallest projects to the biggest projects Redbex supports a wide range of different installation scenarios. Installation scenarios define where the tiers of Redbex are physically installed. There are numerous considerations that should be taken into account when deciding for a specific installation scenario; among them performance, security and compliance with the structure of your existing IT environment.

For installing the three mandatory components, the Application Server, the Application Server Database and the Smart Client there are three common installation scenarios which are described in the following chapters.


Choosing an installation scenario

Last edited: 10/5/2017 11:51:08 AM

If you are familiar with the structure of Redbex it should be easy for you to choose the installation scenario that best fits your requirements and blends smoothly into your IT environment.

Following questions and recommendations may help you with your decision. Note that these are really just recommendations and may not be fully applicable to your specific situation. Changing the installation scenario at a later point in time is possible.

·Do you just want to test drive Redbex?
For test driving Redbex we recommend using the single computer installation scenario. This scenario is the one that takes least time for installation and configuration. Even with the single computer installation scenario you can later install additional clients to test concurrent access to the Application Server.

·Do you want to use Redbex only on a single computer?
Is there only one person who wants to access the product, or has every person who wants to access the product access to that single computer? Can you provide a reliable backup for data on that computer? If the answer to these questions is yes we recommend the single computer installation scenario.

·Do you have an existing server with Microsoft SQL Server running?
If yes, it is in usually wise to utilize that SQL Server for hosting the Application Server Database. Make sure that there is a backup strategy in place for the databases on that SQL Server before you entrust your valuable data to that server. Note that if you already have a server with SQL Server running and that server is also servicing other software or users, the installation of the Redbex Application Server Database might influence the performance of the Database Server. Therefore if you have an existing Microsoft SQL Server running we recommend the fully distributed scenario.

·Do you want to access the Application Servers functionality via internet?
If yes the Application Server must be installed on a Server that faces the Internet and is accessible from clients all over the world. In that case you should also take into consideration that servers facing the internet are exposed to security risks that have to be handled in order to provide information security. For internet faced Servers we recommend the fully distributed scenario.

·Do you want to use a Dedicated Server?
If you are planning install Redbex on a dedicate (virtual) server (a server hosted by some company and not located in your local IT environment) we recommend to use the Small Office installation scenario or if you have high demands for performance use the fully distributed scenario with two servers).

·Do you expect a high system load? Do you expect a high number of users concurrently working with the system, a high amount of processing or huge amounts of data? In that case we recommend the fully distributed scenario.

Deciding between the fully distributed or small office scenario is not always easy to do. Performance and questions on information security must be considered. We cannot provide a definite recommendation since there are too many variables that might influence the decision. However if you are unsure you can always start with the Small office scenario and change to the fully distributed scenario later on.


Scenario 1: Single computer

Last edited: 10/5/2017 11:51:26 AM

This example is the smallest possible installation scenario with the least amount of configuration work to do.

If you decide to use this scenario you will install the Application Server Database, the Application Server and the Smart Client on the same computer.

When to use this scenario

·Only one person uses the system

·The system is not required to be running 24/7 (no continuous data import from other systems etc)

·You are not planning to access the Application Server from other clients via the Internet.

Pro

·Fast installation

·Minimal configuration work needed

·Data transfer between tiers is extremely fast

Con

·Backup must be handled

·Load for database, processing and client on the same computer

·Not very scalable (e.g. when a second user wants to use the system you might have to change your scenario)

Figure 1: Single computer installation szenario


Scenario 2: Small office

Last edited: 10/5/2017 11:51:26 AM

If you decide to use this scenario you will install the Application Server Database and the Application Server on the same machine. The Smart Client is installed on all client Computers from where you want to access the Application Server.

For the communication protocol between Smart Client and Application Server you can choose TCP if you are on a local area network else use HTTP.

When to use this scenario

·More than one person want to access the Application Server from different locations

·You have higher requirements on information security

·You already have an 24/7 server running

Pro

·Backup can be handled by a central server

·Can be used to access data via Internet

·Data transfer between tiers Application Server and Application Server Database

Con

·Load for database and processing on the same computer

·When accessing through the internet both the Database Server and the Application Server are exposed

Figure 1: Example of a small office installation scenario


Multiple instances

Last edited: 10/5/2017 11:51:28 AM

Multiple Instance of the Application Server can be executed one computer at the same time. This option might be useful if you want to have fully separated data repositories but only one machine for hosting the Application Server.

Read chapter Application Server Instances for more details.

Figure 1: Example of a fully distributed installation scenario using multiple instances on a single server.


Changing the installation scenario

Last edited: 10/5/2017 11:51:24 AM

It is possible to change the installation scenario after installation without loosing configuration settings. Following chapters give some basic information what you need to do to change an installation scenario.


Moving the Application Server Databae

Last edited: 10/5/2017 11:51:28 AM

If you want to move the Application Server Database from one database server (source) to another database server (destination) follow following steps.

·Shut down the Application Server Instance that accesses the database you want to move

·Using your favorite SQL Server management software make a backup of the Application Server Database on the source database server

·Transfer the backup files to the destination server

·Using your favorite SQL Server management software restore the database from the backup files to the destination database server.

·Follow the steps in Creating the accessing user to create the login for the Application Server.

·Give the accessing user the permissions to read and write everything in the Redbex Application Server Database

·Modify the instance configuration file of the Application Server Instance that accesses the moved database and point to the right database.


Moving the Application Server

Last edited: 10/5/2017 11:51:28 AM

If you want to move the Application Server from one server (source) to another database server (destination) follow following steps. Note that moving the Application Server will require a new license code.

·Shut down all instances of the Application Server running on the computer

·Make a backup of the directory environment of all Application Server Instances

·Install the Application Server on the new machine using the Application Server Setup Program

·Install additional Application Server instances if needed.

·Overwrite the contents of the directory environment of each instance with data from the backup

·Uninstall the Application Server on the source computer

·Check the settings in the instance configuration files of each Application Server instance

·Start all instances

·Request new license for each instance.


Application Server Database

Last edited: 10/5/2017 11:51:24 AM

This section describes the process of installing the Redbex Application Server Database on a Microsoft SQL Server database server. Microsoft SQL Server itself is not part of Redbex. It has to be downloaded, installed and licensed separately. See chapter SQL Server for more details.

The installation process consists of pre-installation tasks, the execution of the Application Server Database Setup Program and post installation tasks. For a hassle free installation we strongly encourage you to follow the sequence of tasks as described in this section.

Although installation of the Application Server Database is usually straight forward, you should bring basic knowledge about Microsoft SQL Server to understand the following explanations.


Before installation

Last edited: 10/5/2017 11:51:26 AM

Before you actually execute the Application Server Database Setup Program some pre-installation tasks need to be performed. Be sure to complete these preparation work before starting the Setup Program!


SQL Server

Last edited: 10/5/2017 11:51:26 AM

The Application Server Database is a database that runs on Microsoft's SQL Server. Therefore to install the Application Server Database you first have to have a running instance of Microsoft SQL Server. For instruction on how to install SQL Server please refer to the original Microsoft documentation.

Table 1 lists the SQL Server Versions suitable for installing the Application Server Database.

Version | Version No. | Notes
SQL Server 2008 R2 Service Pack 2 | 10.50.40000.0 | Supported editions: Express, Standard, Enterprise, Datacenter, Workgroup. Unsupported editions: Compact Both, x64 and x86 Versions are supported
SQL Server 2012 Service Pack 1 | 11.00.3000.00 | Supported editions: Express, Standard, Enterprise, Workgroup. Unsupported editions: Compact, LightDB Both, x64 and x86 Versions are supported
SQL Serer 2014 (RTM, SP1, or SP2) | RTM: 12.00.2000.8 SP1: 12.0.4100.1 SP2: 12.0.5000.0 | Supported editions: Express, Standard, business Intelligence, Enterprise Both, x64 and x86 Versions are supported

Table 1: Versions of Microsoft SQL Server suitable for installing the Application Server Database

The Express editions of SQL Server have limits that will influence the overall performance of Redbex. Therefore even though Redbex does support the Express Editions these editions might limit the performance and capabilities of your Redbex installation.

Whatever SQL Server version you are using make sure that you have the latest Service Packs for this version installed. To administrate the Database (e.g. add users, change privileges etc) you should also install Microsoft's SQL Server Management Studio (Express) or a similar database management software.

To determine the version of an installed Microsoft SQL Server you can use your favorite database management software (e.g. Microsoft's SQL Server Management Studio) or run the query shown in listing 1 when connected to that database server.

Select @@version

Listing 1: SQL query to determine the version of the database server.


Enabling SQL Server authentication

Last edited: 10/5/2017 11:51:14 AM

This pre installation step is only necessary if you plan to use SQL server authentication for the Accessing user. In that case the SQL Database Server must be configured to allow SQL Server Authentication mode.

If you have already installed SQL Server, the easiest way to check and change the SQL Server authentication mode is by using Microsoft's SQL Server Management Studio. Open the Server Management Studio go to the Object Explorer, right-click on the database server name, select Properties and go to the Security page. On the right side under Server authentication you will see the currently configured Server authentication mode (figure 1:1). After changing the Server authentication mode you will have to restart the database server service. This can be triggered from the context menu of the Database Server in Management Studio's Object Explorer. (figure 2).

If you did not install SQL Server yet you can define the Server authentication mode on installation of the SQL Server. Figure 3 shows the screen in the Microsoft SQL Server installation program where the Authentication mode can be set.

Figure 1: The server properties dialogue in the SQL Server Management Studio

Figure 2: Triggering a restart of the SQL Server in Microsoft SQL Server Management Studio.

Figure 2: Screen during SQL Server installation where you can define the Authentication mode. Here shown for SQL Server 2014 Express.

If you do not want to use Microsoft Management Studio you can find out the currently used Authentication mode of your database server by issue in the SQL command shown in listing 1. To change the SQL Server authentication mode without Management Studio you will have to manually change the Windows Registry, please refer to the original Microsoft Documentation if want to change the Authentication mode that way.

SELECT CASE SERVERPROPERTY('IsIntegratedSecurityOnly')

WHEN 1 THEN 'Windows Authentication'

WHEN 0 THEN 'Windows and SQL Server Authentication'

END as [Authentication Mode]

Listing 1: SQL command to get the currently used authentication mode.


%Text%

Navigation: Administrator's manual > Installation > Application Server Database > Before installation >

Enabling TCP/IP access to SQL Server

Last edited: 10/5/2017 11:51:44 AM

If you are planning to install the Redbex Application Server on a different computer than the Redbex Application Server database you have to allow TCP/IP access for the SQL server. SQL Server versions previous to SQL Server 2014 did enable TCP/IP access by default, starting with the 2014 version TCP/IP is by default disabled!

To enable the TCP/IP protocol in SQL Server 2014, follow these steps:

1.Open SQL Server Configuration Manager

2.Expand “SQL Server Network Configuration” and click on “Protocols for MSSQLSERVER”

3.Right click on TCP/IP and select Enable

4.Click OK on the Warning that the service will have to be restarted

5.Click on SQL Server Services

6.Right click on SQL Server (MSSQLSERVER) and choose Restart


Hardware requirements

Last edited: 10/5/2017 11:51:26 AM

Theoretically the Application Server Database will run on any computer where one of the supported Microsoft Database Servers can be run (see Microsoft's documentation of SQL Server for details). Since the actual hardware requirements above that are depending on the actual usage of the server (number of databases, amount of data written and read etc.) it is not possible to give explicit hardware requirements. Generally - and not surprisingly - the more intense the usage of the Database Server the better hardware you should choose.

The Application Server Database is the place where most of the valuable data is stored. You should therefore choose a hardware that provides the reliability that suits your information security requirements. Also when the Application Server Database is down you won't be able to use Redbex, therefore again you should choose a hardware that provides the reliability you need.

Redbex uses the power of the SQL Server database engine to effectively query and modify data. Therefore the hardware on which the Application Server Database is installed is also crucial for the system's performance. It is simply impossible to give a recommendation on the hardware for the Application Server Database since there are many parameters that influence the needed processing power; among them number of simultaneous users, amount of processing done by the users, amount of processing done by background jobs, amount of data stored in the database etc.

We tested the Application Server Database on simple Laptops as well as on multi processor systems with high performance data storage arrays, Depending on your usage of the System you might need something in between these two extremes. Generally speaking - and again not surprisingly - a database server with more memory more CPU power and faster discs will perform better.

Resource | Minimum Requirement | Recommendation
Network connection to Application Server | 100 MBit/s | ≥1000 MBit/s
 | If not running on the same machine the Application Server Database and the Application Server should be connected through a network with minimal latency and high throughput. A Virtual Private Network (VPN) connection is usually not suitable.
Disk space | 200 | ≥1GB
 | Before installing the Application Server Database you should make sure that you have at least 200MB free disk storage space in the %SQLDATABASEPATH% directory on your Database server.
Processor cores | 1 | ≥4
 | When accessing the Database Server the Application Server uses parallel queries to speed things up. More cores = better performance.

Table 1: Hardware requirements summary


Software requirements

Last edited: 10/5/2017 11:51:42 AM

The Application Server Database Setup Program requires one of the operating systems listed below.

·Windows Server 2008 x64 and x86 versions

·Windows Server 2008 R2 x64 and x86 versions

·Windows 7 x64 and x86 versions

·Windows 8 x64 and x86 versions

·Windows 8.1 x64 and x86 versions

·Windows 10 x64 and x86 versions

·Windows Server 2012 R2 x64

The Setup Program must not necessarily be run on the same computer as the SQL Database Server, but can be run on any computer from where you have access to your Database Server.

To determine hardware and operating system details of a computer you can use Windows' MSINFO32 utility. MSINFO32 displays a comprehensive view of your hardware, system components, and software environment.


Network requirements

Last edited: 10/5/2017 11:51:04 AM

Since the Redbex Application Server accesses the Redbex Application Server Database it is essential that the computer on which the Application Server is installed has a network connection to the Database Server on which the Redbex Application Server Database is hosted.

The SQL Server on which the Application Server Database is hosted must allow connections from the host running the Application Server. If the SQL Server and the Application Server are in the same local network without firewalls and NAT between them (and this scenario is highly recommended) network access is usually no problem. However Windows firewall software might have to be configured to allow the connections to the SQL Server

Microsoft SQL Server is a Winsock application that communicates over TCP/IP by using the sockets network library. SQL Server listens for incoming connections on a particular port. The default port for SQL Server is 1433. The port doesn't need to be 1433, but 1433 is the official Internet Assigned Number Authority (IANA) socket number for SQL Server.


Backup and recovery planning

Last edited: 10/5/2017 11:51:26 AM

Most data managed by Redbex is stored in the Application Server Database. It is therefore crucial to plan for recovery of this data in case of hardware failure, catastrophes, or accidental deletion. We strongly encourage you to take recovery planning really serious.

Planning for backup and recovery before installing the Application Server Database might prevent a later reconfiguration of the system.

Refer to the Backup chapter in this manual for more details.


Security considerations

Last edited: 10/5/2017 11:51:40 AM

Before you start the installation of the Application Server Database you should consider following points that influence security aspects of your Redbex installation.

Accessing user

The accessing user is a SQL Server login or a Windows user (depending on the authentication model used by your SQL Server) that is used by the Application Server to access the data in the Application Server Database.

All read and write operations are performed as that user, therefore that user has full read and write permissions on all data in the database (roles db_datareader and db_datawriter. We suggest to use a separate user account as the accessing user that is only used by the Application Server. As always the password for that user should be a strong password.

For security reasons we also strongly recommend to not use an SQL server login with SQL server roles sysadmin, securityadmin, servaradmin or setupadmin.

If you advice the Setup Program to create the accessing user for you that user will be given the roles db_datawriter and db_datareader automatically.

Manager user

The manager user is a Redbex user that is created during installation of the Application Server database. This user will automatically be granted privileges to read and write most data in Redbex. We recommend to not use this user for your every day work with Redbex but only for administrative tasks. As always the password for that user should be a strong password.


Running the setup program

Last edited: 10/5/2017 11:51:26 AM

This section describes how you use the Application Server Database Setup Program that will create a new Application Server Database on your Microsoft Sql Server. The Setup Program for the latest version of the Application Server Database can be downloaded from http://download.redbex.com.

The Application Server Database Setup Program must not necessarily be run on the Database Server itself but can be run on any computer that can access the database server. To run the Application Server Database Setup Program, membership in the local Windows Administrators group, or equivalent, is required on the machine where the Setup Program is executed.

To successfully conduct the setup you need to have appropriate permissions on the Database Server where you want to install the Application Server Database.


Step 1: Configure

Navigation: Administrator's manual > Installation > Application Server Database > Running the setup program >

Step 1: Preparation

Last edited: 10/5/2017 11:51:04 AM

After starting the Application Server Database Setup Program this program checks some launch conditions such as the version of the operating system, the available memory and others more. If one of these launch conditions is not met the Setup Program will show an appropriate message and will exit immediately.

Note that these launch conditions are checked for the computer on which the Setup Program is executed which is not necessarily the same computer on which you will install the database.

After that the Setup Program will automatically install some software prerequisites that are needed to run the Setup Program. If needed the Setup Program will try to download the needed prerequisites directly from the Internet, therefore if the prerequisites are not already installed an internet connection is mandatory to be able to install the Application Server Database.

The Installation of the software prerequisites may take several minutes to complete.

After all prerequisites have been installed the Setup Program will start the Setup Assistant that will guide you through all remaining setup steps.

Detailed information

Table 1 shows the launch conditions for the Application Server Database Setup Program.

Table 2 lists the software prerequisites that are checked and installed if necessary. Note that these software products are not products of Pöyry Infra GmbH, specific license terms apply to each of these products.

Condition

Description

Administrator permissions

The user running the Setup Program must have administrator permissions.

Operating system

The Setup Program will run only on operating systems listed below

·Windows Server 2008 x64

·Windows 7 x64

·Windows 7 x64 SP 1

·Windows Server 2008 R2 x64

·Windows Server 2008 R2 x64 SP 1

·Windows 8 x64

·Windows 8.1 x64

·Windows 10 x64

·Windows Server 2012 x64

·Windows Server 2008 x86

·Windows 7 x86

·Windows 7 x86 SP 1

·Windows 8 x86

·Windows 8.1 x86

·Windows 10 x64

Minimal physical memory

The Setup Program will only run if there is at least 1 GB of physical memory installed on the computer

Table 1: Launch conditions for the Setup Program.

Software product | Version | Description
Microsoft .NET framework 4.5 | 4.5 | The .NET framework upon which the Application Server is built. If not installed the .NET framework is loaded from the Internet during installation.

Table 2: Software prerequisites checked (and installed) by the Setup Program

Figure 1: Progress indication of prerequisite installation.


Step 1: Starting the Setup Assistant

Last edited: 10/5/2017 11:51:04 AM

If all launch conditions are met and the software prerequisites have been installed the Setup Program shows the welcome screen of the Setup Assistant that will guide you through the following steps.

If at any time during the execution of the Setup Assistant you want to cancel the installation click on the Window close icon in the Assistant's title bar. (figure 1:1)

From the Welcome screen you can open up this installation manual by clicking the Open reference manual button.

Click Next > to continue to the next step of the Setup Assistant.

Figure 1: The Setup Assistant's Welcome screen


Step 2: License agreement

Last edited: 10/5/2017 11:51:04 AM

At this point the Setup Assistant asks you to acknowledge the End User License Agreement of Redbex. If you have not done so before we encourage you to read through the License Agreement and then select I accept the terms of this agreement.

The Next > button is only enabled if you agree to the license terms.

Figure 1: The Setup Assistant's License agreement screen


Step 3: Database server connection

Last edited: 10/5/2017 11:51:04 AM

To install the Application Server Database the Setup Program has to know details about the database server on which the database shall be installed. This includes the address of the Database Server and the credentials that will be used to logon to that database server and create a new database there. In this step the Setup Assistant collects this information.

In the Database server box type either the host name, the full DNS name or the IP address of the computer where the SQL database server on which you plan to install the Application Server Database is installed. On local area networks usually only the machine name is needed. If you run the Setup Program on the computer where the Database Server is installed you can use localhost as Database server name.

If the SQL Server instance you want to install the Database to is a named instance you have to use the following syntax in the Database server box: <servername>\<instancename>.

Examples:

·A default installation of SQL Server Express on the local computer will install a named instance and can be accessed by <hostname>\SQLExpress or alternatively also .\sqlexpress .

·The default instance of an SQL Database Server installed on a computer named OurDatabaseServer located in the local area network can be accessed with OurDatabaseServer

The credentials used to logon to the specified database server and to create the new database can be either a Windows domain account or a local database login. The Setup Program supports Windows domain user accounts only if both the Database Server and the computer on which the Setup Program is executed are in the same Windows domain.

Note: The user you specify for accessing the database server must at least belong to the Db creator and the Security Admin roles. This is not not verified by the Setup Assistant, but the installation will fail if this condition is not met.

The Next > button will only be enabled if all necessary information has been given. When you click on Next > button the Setup Assistant tries to connect to the specified database server with the specified credentials. If that connection fails the Setup Assistant will not continue and you will be notified to correct your settings (figure 2).

The database connection check might take up to 30 seconds.

Figure 1: The Setup Assistant's screen for defining the database server connection used to install the database

Figure 2: Error message shown if the connection to the specified server cannot be established.


Step 4: Database name

Last edited: 10/5/2017 11:51:04 AM

Every database on a SQL Database server must have a unique name. In this step the Installation Assistant asks for the name for the Application Server Database to be installed on your database server. Choose a name that is not yet used for any another database on your database server.

The Next > button will only be enabled if a database name has been given. After clicking the Next > button the Setup Assistant tries to connect to the database server you specified in the previous step and checks if a database with the given name already exists. If so, you will be notified to choose another database name. Checking the database name can take some seconds to complete.

Note that the database name you provide here must be a valid name for a SQL database. This means that the database name may not be longer then 128 characters.

We recommend to name the database Redbex Application Server Database or if you are planning to host more than one Application Server Database on the same Database Server Redbex Application Server Database - <instance name>, e.g. Redbex Application Server Database - Instance01 .

Figure 1: The Setup Assistant's screen to define the name of the Application Server Database


Step 5: Accessing user

Last edited: 10/5/2017 11:51:04 AM

The accessing user is the user that the Redbex Application Server (once installed) will use to connect to the database that is installed here.

In this step you can advice the Setup Program to create a database server login and database user. We call this user the accessing user.

Creation of a database server login and user are optional. If you are in for a quick and easy installation we recommend to let the Setup Program create the user for you.

You can install the database without creating this login, however this is meant for advanced installation scenarios and is only advised if you really have reasons for doing so. If you choose not to create the database login and database user during installation please refer to the chapter Creating the accessing user for a description on how to create the login and database user manually.

Note that not all settings you give in this step can be validated by the Setup Assistant, this has following implications:

1.If you choose to use a Windows login with a windows (domain) user account that does not actually exist, the Setup Program will not create it. The Installation will not fail but you will have to create the Windows user manually afterwards. See chapter Creating the accessing user.

2.If you define a SQL server login that does already exist that login will of course not be created. In this case the password for the already existing login will not be changed! However a user mapped to that login will be added to the Application Server Database and the necessary privileges will be granted.

Figure 1: The Setup Assistant'S screen to define the Accessing user for the Application Server Database

With the Create database server login and database user check box you can advice the Setup Program to create the database server login and database user. If this check box is not selected you will have to create the login and database user manually. By default this check box is enabled.

With the Authentication mode option group you define the authentication mode for the login that wil be created. Select Windows authentication if you want to create a database server login that is mapped to an existing Windows user account. This can be either a local Windows user account (defined on the Database Server) or a Windows domain account.

Select SQL Server authentication if you want to create a login that is based on SQL servers own authentication mechanism. The default for this option group is SQL Server authentication. The user name you define is used both for the database server login and for the database user.

If using SQL Server authentication the Database Server you use must be configured to allow SQL Server authentication. After clicking Next > the Setup Assistant will check if the chosen SQL Server allows SQL Server authentication, and will display a Message if not (see figure 2).

Figure 2: Message shown if the specified database server does not support SQL authentication mode

If you chose Username / password authentication you have to provide a user name and a password. The password has to be typed two times in the Password and Repeat password box. If there is an existing login with the same name as name you specified in the User name box the Setup Assistant will take that user. In this case the password you provided is not used (the existing login's password will be unchanged). To enforce the security of your system and to satisfy the password policies your SQL Server might enforce the password has to conform to following rules:

·Password must not contain the user name (case insensitive). If the username is less than three characters long, this check is skipped.

·Passwords must not contain the words Redbex, Server, User, Application (case insensitive)

·Passwords must contain characters from three of the following five categories:

oUppercase characters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)

oLowercase characters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)

oBase 10 digits (0 through 9)

oNon alphanumeric characters: ~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/

oAny Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.

If you chose Windows authentication you have to provide a user name. For specifying a local Windows user account simply type the user name or optionally .\<username> to explicitly advice the database server to use the local windows account. For specifying domain user accounts use <domain>\<username>.

The Next button in this step of the Setup Assistant is only enabled if you have entered valid data.


Step 6: Manager user

Last edited: 11/8/2017 9:27:28 AM

The Manger user is a Redbex internal user that is created by the Application Server Database Setup Program.

Redbex implements its own user and authentication system. To be able to log on to the Application Server a first user has to be created. In this step the Setup Assistant asks you for a name and a password for that user. Since this is the user that will be used to create other users and to do the initial configuration of the system we refer to this user as the manager user, we also suggest to use Manager as username.

The user created by the Setup Program will be granted all system permissions an all domain permission on the root domain.

To enforce the security of your Redbex installation the password must conform to following rules:

·Password must not contain the user name (case insensitive). If the username is less than three characters long, this check is skipped.

·Passwords must not contain the words Redbex, Server, User, Application (case insensitive)

·Passwords must contain characters from three of the following five categories:

oUppercase characters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)

oLowercase characters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)

oBase 10 digits (0 through 9)

oNon alphanumeric characters: ~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/

oAny Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.

Figure 1: The Manager user screen of the Setup Assistant


Step 7: Installation

Last edited: 10/5/2017 11:51:04 AM

After the Setup Assistant has collected all necessary information it will show a dialogue from where you can start the actual installation. Till this step no changes were made to your system, so it is safe to exit at this point if you do not want to install the Application Server Database.

After clicking on Install the Setup Program will Install the Application Server Database on your Database Server. The installation might take a few minutes to complete, after that another screen will inform you about the success of the installation.

Figure 1: If you click 'Install' on this screen the installation starts. Till this point no modifications have been made to your system.

Figure 2: Installation progress screen

Figure 3: After successful installation this screen is shown.


Summary of installation actions

Last edited: 10/5/2017 11:51:04 AM

Below you find a summary of what changes the Setup Program makes to your system and to your database server. The information below is meant for the technically inclined user. The summary is not necessarily a complete listing of all performed changes.

During Preparation the Setup Program checks if .NET framework 4.5 is installed on the system on which the Setup Program is executed. The Setup Program needs this framework internally and will install it automatically if it is not found. The .NET 4.5 framework is not needed on the database server. If the installation fails after installing the prerequisites the already installed prerequisites will not be removed.

During the installation the Setup Program will connect to the database server you specified in and will create a database with the defined name.

The Setup Program will choose the server default values for Collation, Recovery model, and Compatibility level for the newly created database. For the folder for database files the Setup Program chooses %SQLDATABASEPATH%, for the log folder the Setup Program chooses %SQLLOGPATH%.

The initial database size is set to 100MB. You can use the Microsoft SQL Server Manager or any other database server management software if you need to change these or other properties of the database to suit your local conditions, however be extremely careful when doing so and always make a backup before you apply any changes!

After that the Setup Program will create the database schema for the Redbex Application Server Database. This includes tables, views, stored procedures UDDTs and other SQL server objects.

After successful creation of the database schema the Setup Program will create some basic data within the newly created database. This basic data is needed by the Application Server to operate and includes data for the manager user.

The Setup Program will then create a Database login and a database user according to the settings you specified in step 5 of the Setup Assistant.


If installation fails

Last edited: 10/5/2017 11:51:22 AM

If the installation of the Application Server Database fails the Setup Program will display an appropriate message.

The Setup Program checks a lot of preconditions before actually installing something on your database server and tries to detect all kinds of problems that might hinder a successful installation, however there might still be circumstances in which the installation fails.

Common reasons for a failing installations are listed in table 1. Additional information is available in the installation log file that is by default opened after a failed installation (and also stored in the current Windows user's temporary directory (%Temp% environment variable or CurrentUser\AppData\Local\Temp\ for Windows Vista or later.). The log files are named MSI*.log. If cannot determine the reason for yourself please contact out support.

Due to technical restrictions, the Setup Program may not be able to cleanup nicely, therefore there might be some changes to your system that are not rolled back after a failed installation.

If you installation fails you should check if any database objects have been created on the specified database server and you should delete them manually. Please use your favorite SQL Server Manager software for doing so, and use extreme caution before deleting any objects! See chapter Changes to your systems for details on modifications that might have been done to your database server.

Reason | Checks & Actions
Not enough disk space on database server | Check disk space before installing.
Missing privileges | Check privilege before installing. See Database server connection for more details.

Table 1: Common reasons for a failing installation of the Application Server Database

Figure 1: This screen is shown if the installation fails. Select 'Show log' to immediately display the installation log


After installation

Last edited: 10/5/2017 11:51:32 AM

To finalize the installation of the Application Server database some post-installation tasks must be completed. Following chapters describe these steps.


Creating the accessing user

Last edited: 10/5/2017 11:51:12 AM

This post installation step is only necessary if you did not advice the Setup Program to create a database server login and database user during installation.

Below you find information on how to prepare the Database Server and the Application Server Database to provide access for the Application Server.

Creating an SQL Server login

Before the Application Server accesses the Database Server to read and write data from and to the Application Server Database the Application Server has to first authenticate against the SQL Server. In other words a login (or in SQL Server terms a principal) has to be created on the Database Server that will be later used by the Application Server.

SQL Server can authenticate logins using its own internal mechanism, or it can rely on Windows to authenticate logins. Each of these approaches has its advantages and disadvantages, for a detailed discussion on this please refer to the SQL server documentation. As far as Redbex is concerned both authentication mechanisms are fine and you can choose whatever fits better to in your environment.

When authentication relies on Windows user accounts or groups these can belong either to the local machine or to a Windows domain. When using log on to SQL Server using Windows authentication, the windows user account or the windows user group must be created as a login in SQL Server. Listing 1 shows shows a template for creating an SQL server principal based on a windows user account or windows user group. Listing 2 shows an example for creating a principal based on a windows domain user. Bare in mind that when using windows users for SQL server that the windows password expiration rules might disable logins at some point in time.

CREATE LOGIN [<windows user or user group>]

FROM WINDOWS

WITH DEFAULT_DATABASE = [<YourRedbexDatabaseName>];

Listing 1: Template for creating an SQL server principal based on a windows user account or user group.

CREATE LOGIN [windowsdomain\user1]

FROM WINDOWS

WITH DEFAULT_DATABASE = [Redbex Application Server Database];

Listing 2: Example for creating an SQL server principal based on a windows domain user account.

Listing 3 shows a template that can be used to create a login based on SQL Server's internal authentication mechanism.

CREATE LOGIN [<LoginName>]

WITH PASSWORD = '<your password>',

DEFAULT_DATABASE = [<YourRedbexDatabaseName>],

CHECK_EXPIRATION = OFF,

CHECK_POLICY = OFF;

Listing 3: Template for creating an SQL server principal based on a SQL Server's internal authentication mechanism.

The SQL server principal created does not need and should not have any specific server roles.

Creating a database user

The login you crated in the previous step now needs to be added as database user for the Application Server Database. In SQL Server Database user principals are the database-level security context under which requests within the database are executed, and are associated with either SQL Server or Windows logins.

The template shown in Listing 4 will create a new user within the Application Server database and associate this user with the specified login (principal) you created earlier. When Application Server with this login attempts to access the Application Server Database, it will do so under the security context of the here created database user within that database.

USE [<YourDatabaseName>]

GO

CREATE USER [<Your selected username>]

FOR LOGIN [<YourSQLServerLoginName>];

GO

Listing 4: Template for creating a database user

To be able to perform the necessary data modification operations the database user used by the Application Server has to have specific database roles. These are the roles: db_datareader, db_datawriter. Listing 5 shows a template for adding a user to these role.

USE [<YourDatabaseName>];

GO

EXEC sp_addrolemember N'db_datareader', N'<Your selected username>';

EXEC sp_addrolemember N'db_datawriter', N'<Your selected username>';

GO

Listing 5: Template for adding the database user to database roles.

Listing 6 shows a complete example for creating a database user. We suggest to use the name RedbexApplicationServer for both the SQL server login and the database user. This example uses a windows domain user.

CREATE LOGIN [company\RedbexApplicationServer]

FROM WINDOWS

WITH DEFAULT_DATABASE = [Redbex Application Server Database];

GO

USE [Redbex Application Server Database]

GO

CREATE USER [Redbex Application Server]

FOR LOGIN [company\RedbexApplicationServer];

GO

EXEC sp_addrolemember N'db_datareader', N'Redbex Application Server';

EXEC sp_addrolemember N'db_datawriter', N'Redbex Application Server';

GO

Listing 3: Template for creating an SQL server principal based on a SQL Server's internal authentication mechanism.


Backup plan modification

Last edited: 10/5/2017 11:51:06 AM

After the successful installation of the Application Server Database, please double check that you include the newly created database in your backup procedure. Refer to the Backup chapter for more details on backup planning.


Operating system configuration

Last edited: 10/5/2017 11:51:18 AM

While it is far out of scope for this Reference Manual to provide a guide on how to configure the operating system on which the SQL Server hosting the Application Server Database is run we want to point out a few things that you should definitely think about when you install an SQL Server.

Firewall

Firewall systems help prevent unauthorized access to computer resources. If a firewall is turned on but not correctly configured, attempts to connect to SQL Server might be blocked. You have to make sure that the SQL Server can be accessed from the computer where you plan to install the Application Server.

Please refer to chapter Firewall configuration for more details.

Anti virus

While anti virus software of course helps to protect your computer systems, the decision if you should or should not install antivirus protection software on your database server is not as easy. and is depending on your special environment.

In Knowledge Base article KB309422 Microsoft says following:

"We strongly recommend that you individually assess the security risk for each computer that is running SQL Server in your environment and that you select the tools that are appropriate for the security risk level of each computer that is running SQL Server. Additionally, we recommend that before you roll out any virus-protection project, you test the whole system under a full load to measure any changes in stability and performance."

Windows updates

If you are planning for highest availability of the Database Server you should configure Windows Update accordingly. If not, the Windows Update might automatically download and install Updates and then reboot your server. However if you turn off automatic updates you will have to care about necessary security updates yourself in order to secure your system.


Application Server

Last edited: 10/5/2017 11:51:24 AM

This section describes the process of installing the Redbex Application Server on a computer system. Being a software that acts as a server the Application Server is perhaps not as easy to install as some other software products, however if you follow the procedures as described in this section the installation is straight forward.

Note that membership in the local Windows Administrators group, or equivalent, is the minimum required to complete the Application Server installation.

The installation process consists of some pre-installation tasks, the execution of the Setup Program and some post-installation tasks, we strongly recommend to follow the sequence of tasks as described in this section.


Before installation

Last edited: 10/5/2017 11:51:24 AM

In many cases you can just start the Application Server Setup Program and follow the steps of the Setup Assistant to successfully install the Application Server.

However we recommend to read through following chapters before you actually execute the Setup Program. They include important information that might be necessary to successfully install the Application Server in your Environment.


Hardware requirements

Last edited: 10/5/2017 11:51:24 AM

The Application Server will run on any computer hardware where one of the supported operating systems runs and that has a connection to the internet (for accessing the Distribution Server)

As with most other server software products it is not possible to give explicit hardware requirements for a satisfactory performance of the Application Server since this is totally depending on the usage of the Server (number of concurrently accessing users, amount of data stored, amount of processing performed, other software running on the server etc.).

Following hints should help you selecting the right hardware environment for your installation of the Application Server.

The Application Server makes intensive use of parallel processing, therefore we strongly recommend to use a computer with several CPU cores (or even multiple CPU), think about this especially when you are running the Application Server on a virtual machine. When you are doing a lot of processing (e.g. execution of calculated features) the number of CPU cores becomes more important.

To speed up things the Application Server keeps a lot of data in in-memory-caches. I.e. the Application Server loads data from the Application Server Databases and keeps it in the memory for fast access. Depending on the Server usage this can reach from 200MB to some GB of memory usage.

Most data the Application Server manages is kept in the Application Server Database. One important exception is the storage of binary data, like files. The directory on the server where this data is stored might get huge over time. You should plan for data growth in this directory. We strongly recommend to only use folders on NTFS formatted devices.

It is mandatory that the Application Server can connect to the Distribution Server via the Internet.


Software requirements

Last edited: 10/5/2017 11:51:24 AM

The Application Server can be installed and run on following Operating systems, note that only x64 systems are supported.

·Window Vista x64 SP 2

·Windows Server 2008 x64

·Windows 7 x64 SP 1

·Windows Server 2008 R2 x64 SP 1

·Windows 8 x64

·Windows Server 2012 x64

To determine hardware and operating system details of a computer you can use Windows' MSINFO32 utility. MSINFO32 displays a comprehensive view of your hardware, system components, and software environment.

The Application Server makes use of Microsoft's .NET runtime (version 4.5) and the SQL Server Compact edition (version 4). If these software products are installed by the Setup Program if not found on the computer.

For operation the Application Server needs an SMTP server that it can utilize to send email.


Network requirements

Last edited: 10/5/2017 11:51:24 AM

Access to Distribution Server (Internet connection)

During installation the Setup Program will download missing components from the Redbex Distribution Server. Therefore you will need HTTP access (Port 80) to distribution.redbex.com.

Access to Database Server

Since the Redbex Application Server accesses the Redbex Application Server Database it is essential that the computer on which the Application Server is installed has a network connection to the Database Server on which the Redbex Application Server Database is hosted.

Usually (and this is also highly recommended) the Application Server and the Application Server database are in the same network. If you have a firewall, a NAT service or similar between the Application Server and the Application Server Database be sure to open up all ports needed for SQL server communication. See chapter Application Server Database Firewall configuration for more details.

Outgoing connections

The Application Server needs Internet access via HTTP to download data from the Redbex Distribution Server. If your Application Server is installed behind a Web Proxy Server, i.e. if you have only access to the Internet via a proxy server you have the possibility to configure the HTTP proxy connection during the Setup Assistant for the Application Server.

Theoretically (but not recommended) the Internet connection needs not to be permanent but must be available during installation and during the first start of the Application Server as well as when downloading new data or licenses from the Distribution server. Running the Application Server without Internet access will however make administration cumbersome.

Incoming network connections

Clients can access the Redbex Application Server through HTTP, HTTPS or TCP protocols on the ports configured during Setup. The Application Server must allow connections on these ports. Firewall software (on the Server running the Redbex Application Server, as well as any other firewall Software between the Application Server and the Clients must be configured accordingly. The Windows Firewall on the Server on which the Redbex Application Server is installed can be automatically configured by the Setup Program if advised by the user when running the Setup Wizard.

If you want to run the Application Server in a Network that uses NAT to connect hosts to the Internet, and if you want to connect to the Application Server from the Internet the NAT must be configured accordingly.

Access to SMTP Server

The Application Server uses SMTP (Simple Mail Transfer Protocol) to send login details (username, password, etc) to newly created users. Therefore it is mandatory that you can access an SMTP server and send emails via that server. In the Global Settings you can configure the access parameters.


Security considerations

Last edited: 10/5/2017 11:51:24 AM

During installation of the Application Server you will need to specify three user accounts with passwords:

Service user: The user running the Application Server Windows Service. This is either a local Windows user or a Windows Domain user.

Accessing user: The user that is used by the Application Server to access the Application Server Database. This can be a SQL Server user using SQL authentication or a Windows (Domain) user with Windows authentication. By default this user is created during the installation of the Application Server Database.

Manager user: The first Redbex user created by the Setup to allow initial access to the Application Server.

All these user accounts need a password. We strongly recommend to choose strong passwords for all these accounts. Also we recommend to not use the same passwords since this might temper your overall system security.


Creating the Service User

Last edited: 10/5/2017 11:51:24 AM

This chapter is only important if you do not want the Application Server to create a dedicated local Windows user that runs the Application window service.

The Application Server is run a Windows service, each Windows service executes in the security context of a specific user account. While running the Application Server Setup Program the Setup Assistant gives you the possibility to either automatically create a new local Windows user for that purpose, or to specify an already existing local or active directory user. If you want to specify an already existing user following preparatory steps are mandatory:

·The user must be member of the Windows built-in user groups Users, Performance Monitor Users, EventLogReaders

·Do not use one of the predefined Windows accounts (LocalService, NetworkService or LocalSystem) for running the Application Server.

The service user account can be a local Windows user account or a Windows Domain account. Chapter Creating a local Windows user explains how to create a a local Windows user.

The service user must be member of the Windows built-in user group Performance Monitor Users (SID: S-1-5-32-558). Chapter Adding a local user to a group explains how to add a local user to a local Windows user group.

If you have a Windows Domain controller it may be preferable to use a domain account, since it may allow you to use Windows Authentication for accessing the Application Server Database even if the Database is hosted on a different computer in your network. Additionally Managed Service Accounts (= managed domain accounts available with Windows 2008 R2 and Windows 7 and above) can simplify the management of passwords for the service account.

Use a secure password and advice the Operating system that this password will never expire!

When Windows starts the Windows Service for an Instance of the Application Server, the Windows Service Control Manager (SCM) logs on to the user account associated with the Application Server service. If that logon fails the Application Server service will not start. Note that the SCM does not maintain the passwords of service user accounts (except if using Managed Service Accounts). If a password is expired, the logon fails and the service fails to start. If using managed service accounts Windows will take care of password changing for you.

The user account to run the Application Server service must have the right to Log on as a service in order to be used as the security context of the Application Server Service. The Application Server Setup Program will automatically assign this right to the specified user.

Figure 1 and 2 show the typical settings when using a local user account to run the Redbex Application Server Windows Service. For detailed instructions on how to create a Windows user account (local or domain) please refer to your operating system's documentation.

Figure 1: Typical settings for a local service user (Dialogue as seen in Windows Server 2008R2)

Figure 2: Typical settings for a local service user (Dialogue as seen in Windows Server 2008R2)


Granting SQL Server access

Last edited: 10/5/2017 11:51:24 AM

When running the Application Server Setup Program you will have to specify how the Database Server that hosts the Application Server Database shall be accessed. This information is used to configure the Application Server's database connection settings.

Usually the Accessing user is created and configured by the the Setup of the Application Server Database (see chapter Step 6: Accessing user in the Database Setup). If not refer to Creating the accessing user.

You can always change the database connection configuration after installation of the Application Server instance by modifying the instance configuration file.


Backup and recovery planning

Last edited: 10/5/2017 11:51:24 AM

Before you start installing the Application Server you should plan how you will backup the data managed by the Application Server. Refer to the Backup chapter for more details on backup planning.


One Application Server one Database

Last edited: 10/5/2017 11:51:24 AM

While it is of course theoretically possible to install two Application Servers (on different computers) or two instances of the Application Server on the same computer and configure them so that they access the same Application Server Database this will definitely destroy data in your database. Therefore you should always keep in mind: One Application Server (instance) - one Application Server Database.


Running the Setup Program

Last edited: 10/5/2017 11:51:26 AM

This section describes how you use the Setup Program that actually installs the Application Server software on your computer. The Setup Program for the latest version of the Application Server can be downloaded from http://download.redbex.com. We recommend to download the Setup Program for the latest version before starting with this installation.

If not renamed the setup executable always carries the version in its name e.g: Redbex Application Server 1.22.1161.1250 Setup.exe

The Setup Program must be run on the computer where the Application Server shall be installed. To conduct the setup you need to be member in the local Windows Administrators group, or equivalent.

To log the activities of the Setup Program the executable can be run from the command line with command line parameters. This is useful in case of setup errors and if you want to know what the setup executable really does. Use following syntax to execute the setup executable with logging options:

"<SetupExeFullPath>" /L*V "<LogFileFullPath>"

An example would be:

"C:\SomeDirectory\redbex Application Server 1.0.1161.1250 Setup.exe" /L*V "c:\temp\InstallationLog.txt"


Prerequisites

Last edited: 10/5/2017 11:51:26 AM

After starting the Application Server Setup Program the program checks some launch conditions such as the version of the operating system, the available memory and others. If one of these launch conditions is not met the Setup Program will show an appropriate message and will exit immediately.

After that the Setup Program will automatically install some software prerequisites The Application Server builds upon some other software products, that must be installed before the Application Server can be installed. The Setup Program will check if these software programs are installed. And if not will install them during this step.

If needed the Setup Program will try do download the prerequisites directly from the Internet, therefore if the prerequisites are not already installed an internet connection is mandatory to be able to install the Application Server.

The installation of the software prerequisites (including the possible download from the Internet) may take several minutes to complete.

Figure 1: Progress indicator for prerequisites.


Step 1: Starting the Setup Assistant

Last edited: 10/5/2017 11:51:26 AM

If all launch conditions are met and the software prerequisites have been installed the Setup Program starts the Setup Assistant that will guide you through the following steps.

If you want to cancel the Setup Program you can click on the Window close icon in the Setup Assistants title bar. Note that in that case software prerequisites installed in Step 1: Prerequisites will not be rolled back.

The Preparation screen (figure 1) is shown during the startup of the Setup Program, after that the Welcome screen (figure 2) is displayed. From this screen you can open up the installation manual by clicking the Open reference manual command button.

Figure 1: The Welcome screen of the Setup Assistant.


Step 2: License agreement

Last edited: 10/5/2017 11:51:26 AM

At this point the Setup Assistant asks you to acknowledge the End User License Agreement of Redbex. If you have not done so before we encourage you to read through the License Agreement and then check I accept the terms of this agreement. Note that the Next button is only enabled if you agree to the license terms.

Figure 1: The License Terms screen in the Setup Assistant


Step 3: Installation location

Last edited: 10/5/2017 11:51:26 AM

In this step you can define where all the files for the Application Server are installed. Usually you do not need to change the default location chosen by the Setup Assistant.

This Setup Program will copy all files the Application Server needs to execute into this directory. Additionally the instance configuration file for the primary Application Server instance installed and configured by this Setup Program will be stored in this directory.

If the directory already contains an instance configuration file (usually from a previous installation of the Application Server it will try to read this file and will use the found configuration to preset options in Setup Assistant. When a instance configuration file is found the Setup Assistant will show a Messagebox.

Figure 1: The screen for choosing the location of the Application Server program files


Step 4: Instance identification

Last edited: 10/5/2017 11:51:26 AM

This Setup Program will install the files needed to execute the Application Server and will also install the first instance of the Application Server. Each Application Server instance must be identified by a unique name. In this step you choose the name for the instance created by this Setup Program.

This instance identification is used for having a unique name for the installed Windows Service and is also used as part of the service URI. I.e. when a client wants to connect to the Application Server it will have to know this name.

If you are only planning to run one instance of the Application Server we suggest to go with the default instance identification Redbex.

The instance identifier must conform to following rules

·Must be between 3 and 50 characters long

·Must start with an ASCII letter (a-z or A-Z)

·Must contain only ASCII letters a-z and A-Z, digits 0-9 or underscore character

The instance identifier is checked when you click on Next. If the above listed conditions are not met a message will be shown and you will have to correct the instance identifier before being able to proceed.

Select Start the Redbex Instance Windows Service after installation checkbox if you want the primary instance of the Application Server installed by this Setup Program to be started immediately after the installation completed. Note that regardless of this setting the Application Server Windows Service is configured by the Setup Program to be run whenever the Windows operating system starts.

Figure 1: The instance identification screen


Step 5: Windows Service user

Last edited: 10/5/2017 11:51:26 AM

In this step you have to define the Windows user that will run the Application Server when started as Windows Service. You may either choose to let the Setup Program create a local Windows user for you or you may choose to use an already existing Windows account (local or domain)

Automatically creating a local Windows user

For most installations it will be best to let the Setup Program create a local Windows user for you. Select the option Create local Windows user and provide a User name and a Password for the user to be created. Note that the username must be a username that is not currently existing on your system and it must conform to the rules for windows user names. If you choose a username of an already existing user account or a user name that is not valid for the Windows operating system the Setup Assistant will detect this and will show an appropriate message.

The Password for each Windows user must conform to the password policy enforced by your Windows installation. To ensure that the chosen password will conform to the Windows password policies the Setup Assistant will check following password requirements.

·Passwords must not contain the username (case insensitive). If the username is less than three characters long, this check is skipped.

·Passwords must not contain the words Redbex, Server and User (case insensitive)

·Passwords must contain characters from three of the following five categories:

oUppercase characters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)

oLowercase characters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)

oBase 10 digits (0 through 9)

oNon alphanumeric characters: ~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/

oAny Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.

The Setup Assistant will validate username and password as soon as you select Next, if the chosen password does not fulfill the complexity criteria above a message will be shown.

Note for Windows 10 users: There is a known Issue with some build numbers of Windows 10 (> 10565 and < 14393 that prevents the setup from checking if the user already exists or not (Issue #6638841). On those systems the installer will report a problem at this step. As a workaround you can add two registry settings before running the setup program:

·Run the Registry Editor.

·Browse to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion.

·Add two string values with name RegisteredOwner and RegisteredOrganization and give them some value (e.g. your username and company name)

Using an existing Windows user

If you want to specify an existing Windows user account that should be used to run the Application Server Service select Use existing Windows user (local or domain).

Typical reasons for using an already existing user account would be:

·You are reinstalling the Application Server and therefore you already created the user in a previous installation (the user is not removed on uninstall of the Application Server)

·You want to use a Windows domain account. The Setup Program cannot create Windows domain accounts. Therefore if you want to use a domain account you must create it yourself and then select that user account.

Note that when you want to use an already existing Windows user account you have to care about the right permissions for that user account yourself.

If the existing user is a Windows domain user type the domain and user name into the Domain \ User box in following format: <domain>\<username>. If the user is a local Windows user type the user name in following format: .\<username>. The Setup Assistant will only allow you to proceed if this format specification is met.

The Setup Assistant will check if the credentials are valid when you click on the Next button. During installation the user specified here is given the operating system right Log on as a service.

Figure 1: Advising the Setup Program to create a user for running the Application Server service.

Figure 2: Using an already existing Windows user for running the Application Server service


Step 6: HTTP Proxy configuration

Last edited: 11/8/2017 9:32:08 AM

The Application Server needs Internet connection for downloading update, license etc. from the Redbex Distribution Server, all these connections are done using the HTTP Protocol. If the Computer you are installing the Application Server on has to use a HTTP Proxy to access the Distribution Server you must configure the proxy access in this step of the Setup Assistant.

The Setup Assistant will not verify that a connection can be established and you can move on to the next step without configuring the internet connection, however we strongly recommend to configure working proxy settings at this time. When started first the Application Server will try to perform an Online data update; if the proxy server is not configured this will fail!

The proxy configuration can also be changed after installation in the Global Settings.

In Windows operating systems the Proxy configuration can be set on a per user basis. In some environments these settings are automatically set with Group Policies in other environments each user has to configure the proxy server on its own. Since the Application Server will run as a separate Windows user and (usually) not as the windows user executing the Application Server setup is is usually wise to explicitly configure the proxy server connection here.

If the option Http Internet connection via proxy is set the Application Server will try to directly access the internet via the configured proxy server. If this option is not set the Application Server (once installed) will use the proxy settings he gets from the Windows Operating system. Proxy settings can only be specified if Http Internet connection via proxy is set to true.

The Host and Port boxes specify the proxy server host and the port on which the proxy server will allow HTTP connections. If the Setup Assistant finds that the Windows user running the Application Server Setup is using a proxy server to access the internet it will fill these two boxes with the appropriate values.

In the Host box type the host name, full DNS name (or IP address if you must) of the proxy server e.g. myproxy.mycompany.com . Do not specify a schema (http://myproxy.mycompany.com) or a port (myproxy.mycompany.com:80) in this box. In the Port box specify the port on which the proxy Server listens to requests, ports are positive integer numbers between % and 65535.

If your proxy requires authentication specify the Username and Password. The password has to be given two times to eliminate typos. The password you specify here will be stored encrypted.

The Test Internet connection button can be used to test the proxy settings. Note that if Http Internet connection via proxy is not set this test will try to establish a direct connection to the internet (without the use of a proxy server) since the Setup Assistant has no way of knowing about the Window proxy settings of the user that will run the Application Server later. Once installed the Application Server will use the Windows default proxy settings if it was installed with Http Internet connection via proxy set to false. The test will first validate the proxy settings you specified and will then try to connect to the Redbex Distribution Server at http://distribution.redbex.com. The result of the connection test will be shown in a message box.

Figure 1: The Setup Assistant's HTTP Proxy configuration screen


Step 7: Web service configuration

Last edited: 10/5/2017 11:51:26 AM

The Application Server can be accessed from clients (like the Smart Client) via different Protocols. In this step of the Setup Assistant you can choose which protocols are offered by your installation of the Application Server. Each protocol has advantages and disadvantages you should choose the protocol(s) that best fit your environment. Also not all clients will support communication over every protocol. See table 1 for more details.

Client | Protocols supported
Smart Client | HTTP
GeoMapApp | HTTPS

Table 1: Protocols supported by different clients

In the Setup Assistant dialogue for the protocol configuration select the check boxes for all protocols you want to enable. You can also change the ports on which the Application Server will provide its services. The Application Server will fail to start if it should provide services on a port that is already used by another software therefore the Test ports button provides the possibility test if the ports of the activated protocols are currently used.

The user specified in Step 4: Windows Service configuration will automatically be granted the operating system right to use these (possibly privileged) ports.

After installation changing the protocol configuration given in this step can be easily done by modifying the instance configuration file.

For secure communication between client and Application Server a server certificate is needed. While you can choose to install a certificate signed by a trusted authority the Setup Assistant provides the possibility to create a self signed certificate. If you are not familiar with certificates we suggest to allow the Setup Program to create this self signed certificate for you. Only if you really know what you are doing unselect the Create self signed certificate checkbox.

The Setup Program can automatically create the firewalls for incoming connections on the above specified ports. If Automatically configure Windows firewall is selected one firewall rule will be created for each enabled protocol.

After installation changing the used certificate can be easily accomplished by modifying the instance configuration file configuration file.

Figure 1: The Setup Assistant's Web service configuration screen


Step 8: Folders

Last edited: 10/5/2017 11:51:26 AM

While most data is stored in the Application Server Database the Application Server also uses folders to store some data. This step in the Setup Assistant allows you to configure where those folders are located.

The Logs, Cache, Temporary and Modules folders store data that usually needs no backup, the Binary data folder however is used to store data that needs back up. The Data change logs folder will only be used if you enable the Data Change Log in the Application Server's Global Settings later on. If you plan to use Data Change logging you should also include this directory in your backup.

Depending on your usage of the Application Server the Cache and Temporary folder might need several hundred MB of disc space, the Logs folder needs just minimal disk space. The disk usage of the Binary data folder totally depends on how much binary data you will store with the Application Server.

The disk usage of the Data change logs folder also depends on the usage of the Application Server, you should plan for several Gigabytes of data.

The Logs, Cache and Temporary folder should be located on (fast) local disc drives. The Binary data folder should also be located on a fast drive, but (for reasons of backup) can also be a network share. Note that when using a network share that share must be available for the user running the Application Server service. Mapped network drives are usually not available for the service user. If you what to use a network share use the full UNC path and make sure that the user running the service has access.

If you plan to use data change logging the directory for data change logs should best be placed on a separate local and very fast disk.

The Setup Program will create the folders specified with this dialogue and will set the necessary permissions for these folders. The user specified in step 4 and the Administrators group will get full access to these folders.

After installation changing these folders can be accomplished by modifying the Instance configuration file. and moving the folder contents manually.

Figure 1: The Setup Assistant's Folders screen


Step 9: Database connection settings

Last edited: 10/5/2017 11:51:26 AM

The Application Server needs an Application Server Database as Backend for storing data. You should have already installed an Application Server databases before you install the Application Server. If not exit the Setup Assistant now.

In this step of the Setup Assistant you specify the credentials used to connect to the Application Server Database. You can use the Test connection command button to test the connection parameters. Note that if using Windows authentication mode the connection to the database server will be created using the user configured in step 4 when the Application Server is started as Windows Service. Therefore even if the connection test is successful at this point the connection might fail when the Application Server is started later.

In the Database server box type either the host name, the full DNS name or the IP address of the machine hosting the SQL database server. On local area networks usually only the machine name is needed. If you run the Setup Program on the computer where the Database Server is installed you can use localhost as Database server name.

If you want o connect to a specific SQL Server instance use following syntax:<servername>\<instancename>.

Examples:

·A default installation of SQL Server Express on the local computer can be accessed by localhost\SQLExpress.

·The default instance of an SQL Database Server installed on a computer named OurDatabaseServer located in the local area network can be accessed with OurDatabaseServer

In the Database name box type the name of the database that you created with the Database Setup Program.

The Authentication mode and optionally Username and Password boxes must be set to the values you defined during setup of the Application Server Database.

The connection configuration can be changed after installation by modifying the Instance configuration file.

Figure 1: The Database connection configuration screen in the Setup Assistant.


Step 10: Installation

Last edited: 10/5/2017 11:51:26 AM

After the Setup Assistant collected all necessary information it will show a dialogue where you can start the actual installation. Till this step in the Setup Program no changes were made to your system, so it is safe to exit at this point if you do not want to install the Application Server.

After clicking on Install the Application Server software will be copied to your system and will configured according to the settings you specified. If you advised the Setup Assistant to start the Application Server Windows Service after installation it will be automatically started as soon as the installation is finished. If not you will have to start the Service manually.

Note that the Windows Service for the Application Server is not started automatically at the end of the installation if not advised in Step 4: Windows Service configuration.

Figure 1: Clicking install on this dialogue will start the actual installation of the Application Server

Figure 2: The screen showing the installation progress.

Figure 3: After successful installation this screen will be shown.


Chnages to your system

Navigation: Administrator's manual > Installation > Application Server > Running the Setup Program >

Summary of installation actions

Last edited: 10/5/2017 11:51:26 AM

Table 1 gives an overview of the changes made to your system during the actual installation of the Application Server software. Note that the list of change presented in table one is not complete and only lists changes that might be important to administrators.

Change

Description

Copying of program files

Program files are copied to the specified installation location.

Creation of working directories

Working directories as configured in Step 7: Folders are created. Permissions for the Windows user running the Application Server Service are set.

Service user

If advised in Step 5: Windows Service user the Setup will create a local windows user that is used to run the Redbex Application Server windows service.

Service users group membership for Event Log Readers and Performance Monitor Users is set

System permissions to logon as service is set.

Service user is granted the right to logon as a service and to use the specified (possibly privileged) TCP ports.

Certificate

If advised in Step 7: Web service configuration the self signed Certificate is created and installed. Permissions to read the certificates private key are granted to the Windows User running the Service.

Privileged Ports

If the setup is advised to create a Windows user to run the Application Server service, this user is given the permission to bind to the specified (possibly privileged) TCP ports for network communication.

Windows Service

A Windows Service for the Application Server is created. Its Startup mode is set to Automatic.

If the SQL Database server is detected to be running on the same computer the Setup will create a service dependency, so that the Application Server Service only start after the Database Engine is started.

Instance configuration file

The primary Instance Configuration file is created and stored in the directory of the program files.

Event log source

A new event log source for the Windows Event Log is registered, See Windows Event Log for more details.

Performance counters

The Application Server installation will register several Performance Counters within Window's Performance Monitor framework (perfmon.exe)

Firewall rules

If you advised the Setup Program to create firewall rules for the Application Server there will be one new Windows Firewall rule for every protocol enabled.

Fonts

Redbex Fonts files are installed and registered with Windows.

Table 1: Summary of installation actions


If installation fails

Last edited: 10/5/2017 11:51:26 AM

If the installation fails the Setup Assistant will display a dialog telling you so. In that case the Setup Program will try to roll back all changes that it made so far to your computer system.

If you are not able to detect the cause of the installation problem you should try to run the Setup Program from the command line with the logging option applied. Following command line

c:\>"Redbex Application Server 1.0.1161.1250 Setup.exe" /L*V "example.log"

Doing so will create a log file called example.log. This log file might help you to track down the installation problem yourself and is mandatory for the support to help you with installation problems.

Figure 1: Screen displayed if the Setup Program fails.


After Installation

Last edited: 10/5/2017 11:51:24 AM

Following chapters describe the steps you have to perform after the Setup Program completed successfully.


Running modular updates

Last edited: 11/8/2017 9:32:08 AM

When starting the first time the Application Server will automatically try to load modular updates from the Distribution Server. Make sure that the modular updates ran successfully, else the Application Server will not provide any feature types etc.


Backup plan modification

Last edited: 10/5/2017 11:51:24 AM

After the successful installation of the Application Server, please check that you include the the necessary files and folders in your backup plan. See chapter Backup for more details.


Operating system configuration

Last edited: 10/5/2017 11:51:24 AM

While it is far out of scope for this Reference Manual to provide a guide on how to configure the operating system on which the Application Server is hosted we want to point out a few things that you should definitely think of.

Firewall

Firewall systems help prevent unauthorized access to computer resources. If a firewall is turned on but not correctly configured, attempts to connect to the Application Server may be blocked or the Application Server may not be able to access the Application Server Database, the distribution Server or other online services.

Please refer to chapter Firewall configuration for more details.

Anti virus

Anti virus software helps to protect your computer systems, but it also consumes resources. You have to individually assess the security risk for each computer on which you install the Application server in your environment and then decide which antivirus tools you want to use. If you are using antivirus software to protect your computer we we recommend settings as listed in table 2.

Setting | Reason
Exclude the logging directory from scanning | Depending on your Logging configuration the Application Server writes log entries to files on the file system. For optimal performance these files (or folders) shall be excluded from virus scanning.
Include the file Binary storage directory | In the the Binary storage directory the Application Server stores files that are uploaded by the user. Therefore we recommend to include this directory in virus scanning.
Exclude the Cache directory | The Cache directory is used for persisting system caches. For optimal performance you should exclude this directory from virus scanning.
Exclude the Temp directory | The Temporary directory is by the Application Server whenever it needs to temporarily persist data as files. You should exclude this directory from virus scanning

Table 2: Recommended settings for antivirus software

Windows updates

If you are planning for highest availability of the Application Server you should configure Windows Update accordingly. If not, the Windows Update might automatically download and install Updates and then reboot your server. However if you turn off automatic updates you will have to care about necessary security updates yourself in order to secure your system.

Disk space

Make sure you have enough disk space available for the data the Application Server instance manages. After installation it is mostly the data in the Binary directory that can grow huge. Be sure to reserve plenty of space for this directory.


Detailed installation information

Last edited: 10/5/2017 11:51:24 AM

This chapter provides some more detailed information about the Installation of the Application Server.


Launch conditions

Last edited: 10/5/2017 11:51:24 AM

The Setup Program can only be run if some launch conditions are met. Table 1 shows these launch conditions.

Condition | Description
Administrator permissions | The user running the Setup Program must have administrator permissions on the local machine.
Operating system | The Setup Program will only run on operating systems that are also supported by the Application Server software itself. See software requirements for more details.
Minimal physical memory | The Setup Program will only run if there is at least 1 GB of physical memory installed on the computer

Table 1: Launch conditions for the Setup Program.


Prerequisites

Last edited: 10/5/2017 11:51:24 AM

The Application Server builds upon other software and this software must therefore be installed before the Application Server is run, If the Setup Program detects missing software prerequisites it will automatically install it. Table 1 lists the software prerequisites checked.

Note that these software products are not products of Pöyry Infra GmbH, specific license terms apply to each of these products.

Software product | Version | Description
Microsoft .NET framework 4.5 | 4,5 | The .NET framework upon which the Application Server is built. License:
Microsoft SQL Compact database | 4,0 SP1 | Used for storing temporary data. This is not the database system used for the Application Server Database.
ThinkGeo Map Suite Unmanaged Dependencies | 9.0.93.0 | Used for processing geographical data.

Table 1: Software prerequisites checked (and installed) by the Setup Program

If all prerequisites are already installed the Setup Program will immediately proceed to the next step. If not, the installation of these prerequisites is started.

Please refer to the publishers's documentation of the prerequisite software package for more details. The installation of prerequisites may take several minutes to complete.

Figure 1: Progress indicator for prerequisites.


Smart Client

Last edited: 10/5/2017 11:51:24 AM

This section describes the process of installing the Redbex Smart Client on a computer system.

The installation is done using a standard Windows Setup Program. Three different versions of the Setup Programs are available The full setup, the light setup and the portable setup. While the full setup is usually the best choice since it installs all software prerequisites automatically, it requires Administrator privileges to be run. The light setup as well as the portable setup do not require administrative privileges but some prerequisites have to be fulfilled before they can be run (see table 1 for details).

If you want to install the Smart Client on a portable device (e.g. an USB stick) or if you want to install different Versions of the Smart client in parallel use the portable setup.

Characteristic | Full Setup | Light Setup | Portable Setup
Administrative privileges | Needs administrator privileges to be run | Does not need administrator privileges, every user can run this setup. | Does not need administrator privileges, every user can run this setup.
Install mode | The Smart Client will be installed (and therefore available) for all users on this computer. | The Smart Client will be only installed (and only available) for the current user. If multiple users on the same computer want to use the Smart Client use the Full Setup or each user will have to install the Smart Client separately. | The Smart Client will be installed in a directory you choose. Everybody who has access to this directory can run the Smart Client.
Microsoft .NET4.5 | The full setup will automatically install Microsoft .NET 4.5 (if not already installed). | The setup will check if Microsoft .NET 4.5 is installed, if not the setup will exit without installing the Smart Client. Starting with Windows 8 .NET 4.5 is part of the operating system. | The setup will check if Microsoft .NET 4.5 is installed, if not the setup will exist without installing the Smart Client. Starting with Windows 8 .NET 4.5 is part of the operating system.
Size of the setup executable | The setup executable is bigger since .NET 4.5 is included (~ 55 MiB) | Setup size is around 40 MiB | Setup size is around 40 MiB
Shortcuts | Shortcuts for the Smart Client and the Reference Manual are created on the Desktop, in the Start menu and in the Start Screen (Depending on your Operating System) | Shortcuts for the Smart Client and the Reference Manual are created on the Desktop, in the Start menu and in the Start Screen (Depending on your Operating System) | No shortcuts are installed.
Auto update | Updates for the Smart Client can be loaded from the Distribution Server. Installation of updates needs Administrative Privileges. | Updates for the Smart Client can be loaded from the Distribution Server. Installation of updates needs no Administrative Privileges. | Updates for the Smart Client cannot be loaded from the Distribution Server

Table 1: Comparison of full setup, light setup and portable setup for the Redbex Smart Client


Hardware requirements

Last edited: 10/5/2017 11:51:26 AM

In short words the Smart Client will run on every hardware platform on which one of the supported Windows Operating Systems can be installed. Table 1 shows a list of recommendations that will guarantee a fluent user experience.

Hardware | Recommendation
Memory (RAM) | We recommend at least 1GB of free (not total) RAM
Disk space | At least 4 GB of free disk space shall be available before installation. Disk space is required for the Smart Client's application files as well as for temporary data written during execution of the Smart Client.
Processor | Any state of the art processor will do, multiple cores may speed up the system significantly.
Screen resolution | While the Smart Client can be run on low screen resolutions such as 1024 x 768 a screen resolution of 1280 x 1024 or higher is recommended for a fluent user experience. The higher the resolution the better you can work with multiple tool windows visible at the same time. The Smart Client is also designed to work well in multi monitor environments.
Connection to Application Server | The faster the better. It is impossible to give specific guidelines here since the overall network performance depends on numerous parameters. We tested the Smart Client with connections to the Application Server in a Local Area Network as well as over Internet connections.

Table 1: Recommendations for the hardware on which the Smart Client is installed


Software requirements

Last edited: 10/5/2017 11:51:26 AM

Software requirements for the Smart clients are minimal. In short words the Smart Client will run in nearly every software environment where one of the supported Operating systems can be installed.

The Smart Client can be installed and run on following Operating systems:

·Windows 7 x86

·Windows 8 x86

·Windows 8.1 x86

·Windows Server 2008 R2 x64

·Windows 7 x64

·Windows 8 x64

·Windows 8.1 x64

·Windows Server 2012 x64

The Smart Client Light setup additionally requires Microsoft .NET 4.5 or higher to be installed.


Network requirements

Last edited: 10/5/2017 11:51:34 AM

Depending on your configuration the Smart Client uses TCP and/or HTTP to access the Application Server, therefore the Smart Client needs to be able to connect to the Application Server on the configured ports.

Firewalls (on the Server as well as on the Client), and other security software (again on the Server as well as on the Client) must be configured accordingly.

Please refer to chapter Firewall configuration for more details.


Running the full setup program

Last edited: 11/8/2017 9:32:30 AM

This section describes how you use the full Setup Program that installs the Smart Client on your computer. The Setup Program for the latest version of the Smart Client can be downloaded from http://download.redbex.com.

We recommend to download the latest version of the Smart Client that is compatible with your Application Server before starting with this installation.


Step 1: Prerequisites

Last edited: 10/5/2017 11:51:24 AM

After starting the Smart Client Setup Program program will check the launch conditions. If one of these conditions is not met the Setup Program will exit immediately. Table 1 shows the launch conditions checked by the Setup Program.

Condition | Description
Administrator permissions | The user running the Setup Program must have administrator permissions.
Operating system | The Setup program will only run on operating systems that are also supported by the Smart Client software itself. See software requirements for more details.
Minimal physical memory | The Setup program will only run if there is at least 1 GB of physical memory installed on the computer. See hardware requirements for more details.

Table 1: Launch conditions for the Setup Program.

If all launch conditions are met the Setup Program also software prerequisites. The Smart Client Setup Program and the Smart Client itself build upon other software and this software must therefore be installed before the Smart Client Setup Program or the Smart Client is run. If the Setup Program detects missing software prerequisites it will automatically install it. Table 2 lists the software prerequisites checked. Note that these software products are not products of Pöyry Infra GmbH, specific license terms apply to each of these products.

Software prerequisites are installed as separate software products and will therefore appear in the Windows list of installed Software. Do not remove those software packages since the Smart Client will not work without them. Software prerequisites will not be uninstalled automatically when you uninstall the Smart Client.

Software product | Version | Description
ThinkGeo Map Suite Unmanaged Dependencies | 9.0.93.0 | Used for processing geographical data.
Microsoft .NET framework 4.5 | 4.5 | The .NET framework upon which the Application Server is built. If not installed the Setup Program will load the .NET framework directly from the Internet.

Table 2: Software prerequisites checked (and installed) by the Setup Program

If all prerequisites are already installed the setup will immediately proceed to Step 2: Starting the Setup Assistant. If not, the installation of these prerequisites is started. The installation of prerequisites may take several minutes to complete.

Figure 1: Progress indicator for prerequisites.


Step 2: Starting the Setup Assistant

Last edited: 10/5/2017 11:51:24 AM

If all launch conditions are met and the software prerequisites have been installed the Setup Program starts the Setup Assistant that will guide you through the following steps.

If at any time during the execution of the Setup Assistant you want to cancel the setup program (without installing anything) click on the Window close icon in the Setup Assistant's title bar. Note that software prerequisites installed before the Setup Assistant was started will not be rolled back in that case.

From the Welcome screen (see figure 1) you can open up this installation manual by clicking the Open reference manual button.

Figure 1: The Setup Assistant's Welcome screen


Step 3: License agreement

Last edited: 10/5/2017 11:51:24 AM

At this point the Setup Assistant asks you to acknowledge the End User License Agreement of Redbex. If you have not done so before we encourage you to read through the License Agreement and then select I accept the terms of this agreement.

The Next button is only enabled if you agree to the license terms.

Figure 1: The Setup Assistant License agreement screen


Step 4: Installation path

Last edited: 10/5/2017 11:51:24 AM

In this step the you can choose where where the Smart Client files will be installed. Usually the path suggested by the Setup Assistant will be appropriate.

Figure 1: The Setup Assistant's screen to choose the installation folder


Step 5: Installation

Last edited: 10/5/2017 11:51:24 AM

After the Setup Assistant collected all necessary information it will show a screen where you can start the actual installation (figure 1).

After clicking on Install the Smart Client software will be copied to your system. As soon as the installation is finished the The Setup Assistant will show the final screen informing you about the success of the installation..

Figure 1: Clicking install on this dialogue will start the actual installation of the Smart Client

Figure 2: Progress display during installation

Figure 3: Screen that appears after successful installation of the Smart Client


Summary of installation actions

Last edited: 10/5/2017 11:51:24 AM

Table 1 gives an overview of the changes made to your system during the installation of the Smart Client. Note that the list of change presented in table one is not complete and only lists changes that might be important to administrators.

Change | Description
Copying of program files | Program files are copied to the folder defined in Step 4: Installation path
Event log source | A new event log source for the Windows Event Log is registered,
Redbex Font | The True Type font Redbex.ttf is installed and registred as windows font.

Table 1: Important changes the Setup Program makes to your system


If installation fails

Last edited: 10/5/2017 11:51:24 AM

In case the Setup Program fails to install the Smart Client on your computer it will try to roll back all changes that it made so far to your computer system and will then inform you about the installation failure.

If you are not able to detect the cause of the installation failure you should try to run the setup executable from the command line with the logging option applied.

"<SetupExeFullPath>" /L*V "<LogFileFullPath>"

An example would be:

"C:\SomeDirectory\Setup.exe" /L*V "c:\temp\InstallationLog.txt"


%Text%

Navigation: Administrator's manual > Installation > Smart Client > Running the full setup program >

Silent Installation

Last edited: 10/5/2017 11:51:24 AM

For deployment of the Smart Client using GPO or SMS, The Smart Client Full Setup Program supports command line parameters that allow you to configure the Setup Program to perform an unattended (no user interaction required), silent (no progress indication displayed) installation.

Listing 1 shows an example how command line parameters can be used to start an unattended silent installation. This example would install the Full version of the Smart Client. Note that even if the Setup Program does not display any messages Windows UAC (User Account Control) might still display a confirmation message.

C:\Users\fiu887\Downloads\>"Redbex Smart Client Full 1.19.15205.15205 Setup.exe" /qn /quiet

Listing 1: Command line for unattended silent installation of the Smart Client using the Light Setup.

To log the actions taken during a silent installation you may use the /L*V command line parameter as described in chapter If installation fails.

Using this command line parameters as shown in listing 1 will install the Smart Client to the default path. Listing 2 shows how you can use another command line parameter to define the installation directory.

C:\Users\fiu887\Downloads\>"Redbex Smart Client Full 1.19.15205.15205 Setup.exe" /quiet /qn APPDIR="C:\Temp\Redbex\Client\"


Running the light setup program

Last edited: 11/8/2017 9:32:30 AM

This section describes how you use the light Setup Program that installs the Smart Client on your computer. We recommend to use the light Setup Program if you cannot get administrative privileges to run the full setup program.

The light Setup Program for the latest version of the Smart Client can be downloaded from http://download.redbex.com.

We recommend to download the latest version of the Smart Client that is compatible with your Application Server before starting with this installation.

The light setup requires Microsoft .NET framework 4.5 to be installed on the computer. If this is not the case for your computer you will have to use the full setup program, or install .NET framework 4.5 manually before running the light setup.


Step 1: Prerequisites

Last edited: 10/5/2017 11:51:24 AM

After starting the light Smart Client Setup Program, the program will check the launch conditions. If one of these conditions is not met the Setup Program will exit immediately. Table 1 shows the launch conditions checked by the Setup Program.

If all launch conditions are met the Setup Program will immediately proceed to Step 2: Starting the Setup Assistant.

Condition

Description

Operating system

The setup program will only run on operating systems that are also supported by the Smart Client software itself. See software requirements for more details.

Minimal physical memory

The Setup program will only run if there is at least 1 GB of physical memory installed on the computer. See hardware requirements for more details.

Microsoft .NET framework 4.5

The light Smart Client builds on the Microsoft .NET framework version 4.5. If this framework is not installed the setup will show an appropriate message (figure 1).

In this case you may either download and install the .NET framework 4.5 yourself or you can use the full setup that will also install the .NET framework for you.

Note that starting from Windows 8 .NET framework 4.5 is part of the operating system.

Table 1: Launch conditions for the light Setup Program.

Figure 1: Message displayed if the .NET 4.5 framework is not installed.


Step 2: Starting the Setup Assistant

Last edited: 10/5/2017 11:51:24 AM

If all launch conditions are met the light Setup Program starts the Setup Assistant that will guide you through the following steps.

If at any time during the execution of the Setup Assistant you want to cancel - without installing anything - click on the Window close icon in the Setup Assistant's title bar.

From this screen in the Setup Assistant (figure 1) you can open up this installation manual by clicking the Open Reference Manual button.

Figure 1: The portable Setup Assistant's Welcome screen


Step 4: Installation

Last edited: 10/5/2017 11:51:24 AM

After the Setup Assistant collected all necessary information it will show a screen where you can start the actual installation (figure 1).

After clicking on Install the Smart Client software will be copied to your system. As soon as the installation is finished the The Setup Assistant will show the final screen informing you about the success of the installation..

Figure 1: Clicking install on this dialogue will start the actual installation of the Smart Client

Figure 2: Progress display during installation

Figure 3: Screen that appears after successful installation of the Smart Client


Summary of installation actions

Last edited: 10/5/2017 11:51:24 AM

Since the light Smart Client Setup Program is designed to be run without administrator privileges it mostly copies files to the directory C:\Users\<username>\AppData\Local\Redbex\Smart Client\Light , and creates links to the Smart Client executable and documentation in the start menu and/or on the user's desktop.

Besides that the file extension .redbexconnection is associated with the SmartClient.exe Program.


If installation fails

Last edited: 10/5/2017 11:51:24 AM

In case the light Setup Program fails to install the Smart Client on your computer it will try to roll back all changes that it made so far to your computer system and will then inform you about the installation failure.

If you are not able to detect the cause of the installation failure please contact technical support.


Silent installation

Last edited: 10/5/2017 11:51:24 AM

For deployment of the Smart Client using GPO or SMS, The Smart Client Light Setup Program supports command line parameters that allow you to configure the Setup Program to perform an unattended (no user interaction required), silent (no progress indication displayed) installation.

Listing 1 shows an example how command line parameters can be used to start an unattended silent installation. This example would install the Light version of the Smart Client. Note that even if the Setup Program does not display any messages Windows UAC (User Account Control) might still display a confirmation message.

C:\Users\fiu887\Downloads\>"Redbex Smart Client Light 1.19.15205.15205 Setup.exe" /VERYSILENT /SUPPRESSMSGBOXES

Listing 1: Command line for unattended silent installation of the Smart Client using the Light Setup.

To log the actions taken during a silent installation you may use the /Log command line parameter. This parameter causes the Setup to create a log file in the user's temporary directory detailing file installation actions taken during the installation process. This can be a helpful debugging aid. The log file is created with a unique name based on the current date. (It will not overwrite or append to existing files.)

The information contained in the log file is technical in nature and therefore not intended to be understandable by end users. Nor is it designed to be machine-parseable; the format of the file is subject to change without notice.

Alternatively you may also use the /LOG="filename" parameter that has the same effect as the /Log parameter, except it allows you to specify a fixed path/filename to use for the log file. If a file with the specified name already exists it will be overwritten. If the file cannot be created, Setup will abort with an error message.


IN_SC_PO

Navigation: Administrator's manual > Installation > Smart Client >

Running the portable setup program

Last edited: 11/8/2017 9:32:30 AM

This section describes how you use the portable Setup Program that installs the Smart Client on your computer. We recommend to use the portable Setup Program only if you intend to install different versions of the Smart Client in parallel or if you want to install the Smart Client on a portable device like a USB stick.

The portable Setup Program for the latest version of the Smart Client can be downloaded from http://download.redbex.com.

We recommend to download the latest version of the Smart Client that is compatible with your Application Server before starting with this installation.

The portable setup requires Microsoft .NET framework 4.5 to be installed on the computer. If this is not the case for your computer you will have to use the full setup program, or install .NET framework 4.5 manually before running the light setup.


Step 1: Prerequisites

Last edited: 10/5/2017 11:51:24 AM

After starting the Portable Smart Client Setup Program, the program will check the launch conditions. If one of these conditions is not met the Setup Program will exit immediately. Table 1 shows the launch conditions checked by the Setup Program.

If all launch conditions are met the Setup Program will immediately proceed to Step 2: Starting the Setup Assistant.

Condition

Description

Operating system

The setup program will only run on operating systems that are also supported by the Smart Client software itself. See software requirements for more details.

Minimal physical memory

The Setup program will only run if there is at least 1 GB of physical memory installed on the computer. See hardware requirements for more details.

Microsoft .NET framework 4.5

The light Smart Client builds on the Microsoft .NET framework version 4.5. If this framework is not installed the setup will show an appropriate message (figure 1).

In this case you may either download and install the .NET framework 4.5 yourself or you can use the full setup that will also install the .NET framework for you.

Note that starting from Windows 8 .NET framework 4.5 is part of the operating system.

Table 1: Launch conditions for the portable Setup Program.

Figure 1: Message displayed if the .NET 4.5 framework is not installed.


Step 4: Installation location

Last edited: 10/5/2017 11:51:24 AM

Here the Setup Assistant allows you to choose the location where all the program files will be installed.

The Setup Assistant suggests a Windows default directory that is writable for the user running the installation and chooses a subdirectory including the Version number of the Smart Client. This allows to install multiple versions of the Portable Smart Client side by side. However you can of course choose any other installation directory, if you do so make sure that the user running the installation has the rights to write to this directory.

Figure 1: The screen for defining the installation location for the Smart Client.


%Text%

Navigation: Administrator's manual > Installation > Smart Client > Running the portable setup program >

Step 5: Additional Tasks

Last edited: 10/5/2017 11:51:24 AM

Here the Setup Assistant allows you to choose which additional tasks it will perform.

Create a start menu icon: if selected the Setup Program will create a shortcut in the Windows start menu. Note that if you install on a portable medium this link might easily point to a non existing location.

Create a desktop icon: if selected the Setup Program will create a shortcut on the Windows desktop. Note that if you install on a portable medium this link might easily point to a non existing location.

Figure 1: The screen for selecting additional tasks


Step 6: Installation

Last edited: 10/5/2017 11:51:24 AM

After the Setup Assistant collected all necessary information it will show a screen where you can start the actual installation (figure 1).

After clicking on Install the Smart Client software will be copied to the directory you chose. As soon as the installation is finished the The Setup Assistant will show the final screen informing you about the success of the installation..

Figure 1: Progress display during installation

Figure 2: Screen that appears after successful installation of the Smart Client


Summary of installation actions

Last edited: 10/5/2017 11:51:24 AM

Since the portable Smart Client Setup Program is designed to install the Smart Client on portable devices it just copies all the program files to the directory you have chosen.


If installation fails

Last edited: 10/5/2017 11:51:24 AM

In case the portable Setup Program fails to install the Smart Client on your computer it will try to roll back all changes that it made so far to your computer system and will then inform you about the installation failure.

If you are not able to detect the cause of the installation failure please contact technical support.


Application Server Instance

Last edited: 10/5/2017 11:51:24 AM

This section describes the process of installing additional instances of the Redbex Application Server. Before you can install additional Application Server Instances you have to install the Application Server itself!

Membership in the local Windows Administrators group, or equivalent, is the minimum required to complete the Application Server Instance installation.

The setup process consists of some pre-installation tasks, the execution of the Setup Program and some post-installation tasks, we strongly recommend to follow the sequence of tasks as described in this section.


Before installation

Last edited: 10/5/2017 11:51:06 AM

Before you actually execute the Setup Program some preparation work is needed. Be sure to complete these preparation work before starting the installation!


Hardware requirements

Last edited: 10/5/2017 11:51:26 AM

Additional instances of the Application Server will put additional load on the computer. Check the hardware requirements for the Application Server and then check if your hardware can host more than one instance of the Application Server.

We recommend to monitor CPU, Memory and Disk usage of the Server before installing a second instance.


Install Database

Last edited: 10/5/2017 11:51:24 AM

Each instance of the Application Server must have its own Application Server Database (One Application Server Instance - one Database).

Before you install an additional instance of the Application Server you will therefore have to install another Application Server Database. See chapter Application Server Database Installation for details.


Choosing the Windows user

Navigation: Administrator's manual > Installation > Application Server Instance > Before installation >

Creating a Windows user

Last edited: 10/5/2017 11:51:24 AM

Each instance of the Application Server is run a Windows service, each Windows service executes in the security context of a user account. The user name and password of the Windows user account that runs the Application Server Windows service must be specified when running the Application Server Setup Program (and is NOT created by the Setup Program).

All instances of the Application Server can use the same Windows user, however if you want more isolation you can also run each instance as a separate user. Refer to chapter Creating a Windows user for details.


Granting SQL Server access

Last edited: 10/5/2017 11:51:26 AM

When running the Application Server Instance Setup Program you will have to specify how the Database Server that hosts the Application Server Database shall be accessed. This information is used to configure the Application Server's database connection settings.

Usually the accessing user is created and configured by the the Setup of the Application Server Database (see chapter Step 6: Accessing user in the Database Setup). If not refer to Creating the accessing user.

You can always change the database connection configuration after installation of the Application Server instance by modifying the instance configuration file.


Backup and recovery planning

Last edited: 10/5/2017 11:51:24 AM

Before you start installing an additional instance of the Application Server you should plan how you will backup the data managed by the Application Server. Refer to the Backup chapter for more details on backup planning.


Running the setup program

Last edited: 10/5/2017 11:51:34 AM

This section describes how you use the Application Server Instance Setup Program that installs additional instances of the Redbex Application Server on your computer.

The latest version of the of the Application Server Instance Setup Program can be downloaded from http://download.redbex.com. We recommend to for the latest version before starting with this installation.

The Setup Program must be run on the computer where the Application Server instance shall be installed. Note that to run the Setup Program you need to be member in the local Windows Administrators group, or equivalent.


Prerequisites

Last edited: 10/5/2017 11:51:26 AM

After starting the Setup Program for the Application Server the Setup Program will initialize itself and then checks the launch conditions. If one of these conditions is not met the Setup Program will exit immediately.

Since the launch conditions are the same as for the Application Server Setup Program the Setup Program will usually not need to install any additional software.


Step 1: Starting the Setup Assistant

Last edited: 10/5/2017 11:51:26 AM

If all launch conditions are met and the software prerequisites have been installed the Setup Program starts the Setup Assistant that will guide you through the following steps.

If you want to cancel the Setup Program you can click on the Window close icon in the Setup Assistants title bar.

The Preparation screen is shown during the startup of the Setup Assistant, after that the Welcome screen (figure 1) is displayed. From this screen you can open up the installation manual by clicking the Open reference manual command button.

Figure 2: The Setup Assistant's Welcome screen


Step 2: Instance identification

Last edited: 10/5/2017 11:51:42 AM

Each Application Server instance must be identified by a unique name. In this step you choose the name for the instance that shall be created by this Setup Program.

This instance identification is used for having a unique name for the installed Windows Service and is also used as part of the service URI. I.e. when a client wants to connect to the Application Server it will have to know this name.

The Setup Assistant will check the uniqueness of the instance identifier, you will only be able to proceed if the instance identifier is unique.

The instance identifier must conform to following rules

·Must be between 3 and 50 characters long

·Must start with an ASCII letter (a-z or A-Z)

·Must contain only ASCII letters a-z and A-Z, digits 0-9 or underscore character

Figure 1: The instance identification screen


Step 3: Windows Service user

Last edited: 10/5/2017 11:51:26 AM

In this step you have to define the Windows user that will run the Application Server Instance when started as Windows Service. You may either choose to let the Setup Program create a local Windows user for you or you may choose to use an already existing Windows account (local or domain)

Using an existing Windows user

For most Application Server Instance installations it will be best to use the same user for running the Windows service for this instance as the user running the primary (or other) instances on the same computer.

If you want to specify an existing Windows user account that should be used to run the Application Server Service select Use existing Windows user (local or domain).

If the existing user is a Windows domain user type the domain and user name into the Domain \ User box in following format: <domain>\<username>. If the user is a local Windows user type the user name in following format: .\<username>. The Setup Assistant will only allow you to proceed if this format specification is met.

The Setup Assistant will check if the credentials are valid when you click on the Next button. During installation the user specified here is given the operating system right Log on as a service.

Figure 1: Defining an existing user as the user running the Application Server service.

Automatically creating a local Windows user

You may also advise the Setup Program to create a new user for running the Windows service of this instance. This allows you to totally isolate the installations of different instances which might be an advantage in some installation scenarios.

Select the option Create local Windows user and provide a User name and a Password for the user to be created. Note that the username must be a username that is not currently existing on your system and it must conform to the rules for windows user names. If you choose a username of an already existing user account or a user name that is not valid for the Windows operating system the Setup Assistant will detect this and will show an appropriate message.

The Password must conform to the password quality rules of your Windows system. The Setup Assistant will only check that the password is at least 8 characters long. However the Installation will later fail if the password does not Match you local Windows password quality rules.

The Setup Assistant will validate username and password as soon as you select Next.

Figure 2: Advising the Setup Program to create a user for running the Application Server service.


Step 4: Web service configuration

Last edited: 10/5/2017 11:51:26 AM

The Application Server Instance can be accessed from clients (like the Smart Client) via different Protocols. In this step of the Setup Assistant you can choose which protocols are offered by your Instance of the Application Server.

In this step of the Setup Assistant you can define the protocol configuration; select the check boxes for all protocols you want to enable. You can also change the ports on which the Application Server will provide its services. The Application Server will fail to start if it should provide services on a port that is already used by another software therefore the Test ports button provides the possibility test if the ports of the activated protocols are currently used.

Note that Redbex supports port sharing for HTTP but not for TCP. I.e. you can run more than one instance of the Application Server providing its services on the same HTTP port. However, different Instances of the Application Server providing services over TCP have to provide their services on different ports.

The user specified in Step 4: Windows Service configuration will automatically be granted the operating system right to use these (privileged) ports.

After installation changing the protocol configuration given in this step can be easily done by modifying the instance configuration file.

After installation changing the used certificate can be easily accomplished by modifying the instance configuration file configuration file.

Figure 1: The Setup Assistant Protocol Configuration screen in the Setup Assistant


Step 5: Folders

Last edited: 10/5/2017 11:51:26 AM

Each instance of the Application Server must use its own set of folders. While most data is stored in the Application Server Database the Application Server also uses folders to store some data. In this step the Setup Assistant asks for the location of those folders.

The Logs, Cache, Modules and Temporary folder store data that usually needs no backup, the Binary data folder however is used to store data that needs back up.

The Setup Assistant chooses default locations that allow side by side installation of multiple instances of the Application Server. Do not choose the same folders for different instances of the Application Server.

Depending on your usage of the Application Server the Cache and Temporary folder might need several hundred MB of disc space, the Logs folder needs just minimal disk space. The disk usage of the Binary data folder totally depends on how much binary data you will store with the Application Server.

The Logs, Cache and Temporary folder should be located on (fast) local disc drives. The Binary data folder should also be located on a fast drive, but (for reasons of backup) can also be a network share.

The Setup Program will create the folders specified with this dialogue and will set permissions for these folders. The user specified in step 4: Windows Service configuration will get full access to the folder as well as the Administrators group.

After installation changing these folders can be accomplished by modifying the Instance configuration file and manually copying the contents to the new location.

Figure 1: The Setup Assistant's Folders screen


Step 2: Database connection settings

Last edited: 10/5/2017 11:51:26 AM

Each instance of the Application Server needs its own Application Server database. In this step the Setup Assistance asks for the connection settings to that database. You should have already installed a database for this new instance of the Application Server databases before you install the Application Server Instance.

Every Instance of the Application Server must connect to its own Application Server Database. If two or more instances are connecting to the same Application Server Database this will result in data loss!

You can use the Test connection command button to test the connection parameters. Note that if using Windows authentication mode the connection to the database server will be created using the user configured in step 4 when the Application Server is started as Windows Service. Therefore even if the connection test is successful at this point the connection might fail when the Application Server is started later.

In the Database server box type either the host name, the full DNS name or the IP address of the machine hosting the SQL database server. On local area networks usually only the machine name is needed. If you run the Setup Program on the computer where the Database Server is installed you can use localhost as Database server name.

If you want o connect to a specific instance use following syntax <servername>\<instancename>.

Examples:

·A default installation of SQL Server Express on the local computer can be accessed by localhost\SQLExpress.

·The default instance of an SQL Database Server installed on a computer named OurDatabaseServer located in the local area network can be accessed with OurDatabaseServer

In the Database name box type the name of the database that you created with the Database Setup Program.

The Authentication mode and optionally Username and Password boxes must be set to the values you defined during setup of the database.

The connection configuration can be changed after installation by modifying the Instance configuration file

Figure 1: The Database connection configuration dialogue


Step 8: Installation

Last edited: 10/5/2017 11:51:26 AM

After the Setup Assistant collected all necessary information it will show a dialogue where you can start the actual installation (or quit). Till this step in the Setup Program no changes were made to your system, so it is safe to exit at this point if you do not want to install the Application Server.

After clicking on Install the Application Server software will be copied to your system and will configured according to the settings you specified. As soon as the installation is finished you can start the Application Server Instance Windows Service.

Note that the Windows Service for the Application Server is not started automatically at the end of the installation use the Windows service control panel to start the service.

Figure 3: After successful installation this screen will be shown.


Chnages to your system_2

Navigation: Administrator's manual > Installation > Application Server Instance > Running the setup program >

Summary of installation actions

Last edited: 10/5/2017 11:51:26 AM

Table 1 gives an overview of the changes made to your system during the actual installation of the Application Server software. Note that the list of change presented in table one is not complete and only lists changes that might be important to administrators.

Change | Description
Copying of configuration files | Configuration are copied to the default windows location for programs
Creation of working directories | Working directories as configured in Step 6: Folders are created. Permissions for the windows user running the Application Server Service are set.
Privileged Ports | The user running the Windows Service is given the permission to use privileged ports for network communication.
Windows Service | A windows Service for the Application Server is created. Its Startup mode is set to automatic.

Table 1: Summary of installation actions


If installation fails

Last edited: 10/5/2017 11:51:22 AM

If the installation fails the Setup Assistant will display a dialog telling you so. In that case the Setup Program will try to roll back all changes that it made so far to your computer system.

If you are not able to detect the cause of the installation problem you should try to run the Setup Program from the command line with the logging option applied. Following command line

c:\>"Redbex Application Server Instance 1.0.1161.1250 Setup.exe" /L*V "example.log"

Doing so will create a log file called example.log. This log file might help you to track down the installation problem yourself and is mandatory for the support to help you with installation problems.


After installation

Last edited: 10/5/2017 11:51:02 AM

Following chapters describe the steps you have to perform after the Setup Program for an Application Server Instance completed successfully.


Backup plan modification

Last edited: 10/5/2017 11:51:24 AM

After the successful installation of an additional instance of the Application Server, please check that you include the the necessary files and folders in your backup plan. See chapter Backup for more details.


Operating system configuration

Last edited: 10/5/2017 11:51:26 AM

While it is far out of scope for this Reference Manual to provide a guide on how to configure the operating system on which the Application Server is hosted we want to point out a few things that you should definitely think of after installing an additional Application Server instance

Firewall

Firewall systems help prevent unauthorized access to computer resources. If a firewall is turned on but not correctly configured, attempts to the Application Server may be blocked. You have to make sure that the Application Server can be accessed from the computer where you plan to install the Application Server.

Disk space

Make sure you have enough disk space available for the data the Application Server instance manages. Especially check the Binary directory.


Update

Last edited: 10/5/2017 11:51:44 AM

Following chapters explain how to update the tiers of the Redbex software system to a new version.


Application Server Database

Last edited: 10/5/2017 11:51:44 AM

With the Application Server Database Update Program you can update the structure and data of installed Application Server Databases to the a later version. The Redbex Application Server requires that the database it accesses is in a specific version i.e. the database server expects a specific structure of the database. Whenever you update the Application Server you will therefore have to check which Database Version is required and if a later version is required you will have to run the Application Server Database Update Program on all databases that are used by instances of that Application Server.

Updating the structure of a database is a process that can fail for many reasons and may leave the database in an inconsistent state. Therefore it is absolutely mandatory to have a backup of the database you update before starting the update process.

Application Server Updates are done using the Application Server Update Program distributed by Pöyry Infra GmbH.


Software requirements

Last edited: 10/5/2017 11:51:42 AM

The Application Server Database Update Program requires one of the operating systems listed below.

·Windows Server 2008 x64 and x86 versions

·Windows Server 2008 R2 x64 and x86 versions

·Windows 7 x64 and x86 versions

·Windows 8 x64 and x86 versions

·Windows 8.1 x64 and x86 versions

·Windows Server 2012 R2 x64

The Update Program must not necessarily be run on the same computer as the SQL Database Server that hosts the database to be updated, but can be run on any computer from where you have network access to your Database Server.

To determine hardware and operating system details of a computer you can use Windows' MSINFO32 utility. MSINFO32 displays a comprehensive view of your hardware, system components, and software environment.


Before updating

Last edited: 10/5/2017 11:51:06 AM

Before you perform the database update you should shut down the Application Server Instance using that Application Server Database.

Updating a database might take somewhere from a few seconds to a few hours depending on the number of updates steps performed and depending on the amount of data in your database. Therefore be sure to plan for a longer downtime of your Application Server.

Updating the structure of a database is a process that can fail for many reasons and may leave the database in an inconsistent state. Therefore it is absolutely mandatory to have a backup of the database you update before starting the update process.


Running the update program

Last edited: 10/5/2017 11:51:34 AM

This section describes how you use the Application Server Database Update Program that will update the Application Server Database to a later version. The Update Program for the latest version of the Application Server Database can be downloaded from http://download.redbex.com.

The Application Server Database Update Program must not necessarily be run on the Database Server itself but can be run on any computer that can access the database server. To run the Application Server Database Update Program, membership in the local Windows Administrators group, or equivalent, might be required on the machine where the Update Program executed.

While running the setup program you will have to specify the credentials used to connect to the database you want to update. These credentials must have appropriate SQL-Server permissions to modify the Application Server Database to be updated.

The Version of the Update Program also specifies the latest version of the Application Server Database this program can update to, i.e. the program can update all Databases with a version number lower than the version of the Update Program and will update these databases to the same version as the Update Program.

The Update Program will update the database version by version. E.g. if the Update Program is of version 1.9.3.0 and your current database version is 1.7.1.3 the Update Program might need to perform an update from 1.7.1.3 to 1.7.1.5 then to 1.8.0.0 then to 1.8.5.1 and finally to 1.9.3.0. This also means that the update program can be applied to every version of the Application Server Database and will automatically determine the steps necessary to update it to the latest version.


Prerequisites

Last edited: 10/5/2017 11:51:32 AM

After starting the Application Server Database Update the Update Program checks some launch conditions such as the version of the operating system, the available memory and others. If one of these launch conditions is not met the Update Program will show an appropriate message and will exit immediately.

Note that these launch conditions are checked for the computer on which the Update Program is executed which is not necessarily the same computer on which the database to be updated is hosted.

After that the Update Program will automatically install some software prerequisites that are needed to run the Update Program. The Installation of the software prerequisites may take several minutes to complete. After all prerequisites have been installed the Update Program will start the Update Assistant that guides you through the steps of updating an Application Server Database

Detailed information

Table 1 shows the launch conditions for the Application Server Database Update Program.

Table 2 lists the software prerequisites that are checked and installed if necessary. Note that these software products are not products of Pöyry Infra GmbH, specific license terms apply to each of these products.

Condition

Description

Administrator permissions

The user running the Update Program must have administrator permissions.

Operating system

The Update Program will run only on operating systems listed below

·Windows Server 2008 x64

·Windows 7 x64

·Windows 7 x64 SP 1

·Windows Server 2008 R2 x64

·Windows Server 2008 R2 x64 SP 1

·Windows 8 x64

·Windows Server 2012 x64

·Windows Server 2008 x86

·Windows 7 x86

·Windows 7 x86 SP 1

·Windows 8 x86

Minimal physical memory

The Update Program will only run if there is at least 1 GB of physical memory installed on the computer

Table 1: Launch conditions for the Update Program.

Software product | Version | Description
Microsoft .NET framework 4.5 | 4,5 | The .NET framework upon which the Application Server is built.

Table 2: Software prerequisites checked (and installed) by the Update Program


Step 1: Starting the update assistant

Last edited: 10/5/2017 11:51:42 AM

If all launch conditions are met and the software prerequisites have been installed the Update Program shows the welcome screen of the Update Assistant that will guide you through the following steps.

If at any time during the execution of the Update Assistant you want to cancel the installation click on the Window close icon in the Assistant's title bar. (figure 1:1)

From the Welcome screen you can open up this Reference Manual by clicking the Open reference manual button.

Click Next > to continue to the next step of the Setup Assistant.

Figure 1: The Update Assistant's welcome secreen


Step 2: Database connection

Last edited: 10/5/2017 11:51:42 AM

In this step you specify the database that shall be updated, and the credentials used to connect to that database.

In the Database server box type either the host name, the full DNS name or the IP address of the computer where the SQL database server on which the Application Server Database you whish to update is installed. On local area networks usually only the machine name is needed. If you run the Update Program on the computer where the Database Server is installed you can use localhost as Database server name.

If the SQL Server instance you want to install the Database to is a named instance you have to use the following syntax in the Database server box: <servername>\<instancename>.

Examples:

·A default installation of SQL Server Express on the local computer will install a named instance and can be accessed by <hostname>\SQLExpress or alternatively also .\sqlexpress .

·The default instance of an SQL Database Server installed on a computer named OurDatabaseServer located in the local area network can be accessed with OurDatabaseServer

The credentials used to logon to the specified database server and to create the new database can be either a Windows domain account or a local database login. The Update Program supports Windows domain user accounts only if both the Database Server and the computer on which the Update Program is executed are in the same Windows domain.

Note: The user you specify for accessing the database server must at least belong to the Db creator and the Security Admin roles. This is not not verified by the Setup Assistant, but the installation will fail if this condition is not met.

The Next > button will only be enabled if all necessary information has been given. When you click on Next > button the Update Assistant tries to connect to the specified database server with the specified credentials. If that connection fails the Setup Assistant will not continue and you will be notified to correct your settings (figure 2).

The database connection check might take up to 30 seconds.

Figure 1: The Update Assistant's screen for defining the database to be updated

Figure 2: This message is shown if defined database connection cannot be established.


Step 3: Starting the update

Last edited: 10/5/2017 11:51:42 AM

In this step in the Setup Assistant shows the update steps that will be performed on the selected database.

For this the Update Assistant first connects to the database to be updated and reads its version. Based on this information the Update Assistant determines which update steps will be applied.

Before clicking Update this is now your last chance to double check that you have an existing Backup for the database. As soon as you click Update the Update Program will begin altering the structure of your database.

Figure 1: The screen showing the update steps to be performed.

Figure 2: The screen shown while the Update Program is changing the database structure

Figure 2: The screen shown if the update was successfully performed.


If installation fails

Last edited: 10/5/2017 11:51:22 AM

If the update of the Application Server Database fails the Update Program will display an appropriate message.

The Update Program checks a lot of preconditions before actually changing the structure of your Application Server Database and tries to detect all kinds of problems that might hinder a successful update, however there might still be circumstances in which the installation fails.

Common reasons for a failing installations are listed in table 1. Additional information is available in the installation log file that is by default opened after a failed installation (and also stored in the current Windows user's temporary directory (%Temp% environment variable or CurrentUser\AppData\Local\Temp\ for Windows Vista or later.). The log files are named MSI*.log. If cannot determine the reason for yourself please contact out support.

If you installation fails you should restore the database from backup, before trying to run the Update Program again.

Reason | Checks & Actions
Not enough disk space on database server | Check disk space before installing.
Missing privileges | Check privilege before installing. See Database server connection for more details.

Table 1: Common reasons for a failing installation of the Application Server Database


Application Server

Last edited: 10/5/2017 11:51:02 AM

To update the Application Server to a later version you basically need to uninstall the the Application Server first and then run the Setup for the new Version of the Application Server.

The Application Server Setup Program will automatically detect if a previous (older) version of the Application Server is already installed. If so, the Setup Program will inform you that you have to uninstall the currently installed version first.

Uninstalling the previous version of the Application Server will not delete the files in the binary directory, cache directory, log directory, modules directory, optional logs directory, or temporary directory. The instance configuration file in the application directory will also not be deleted. When installing the new version (in the same application directory) the Setup Program will find the instance configuration file and will use the settings from this file as default values for all steps in the Setup Assistant.


Smart Client Full

Last edited: 10/5/2017 11:51:44 AM

The Smart Client Setup Program will automatically detect if a previous (older) version of the Smart Client is already installed. If so, the first screen (figure 1) of the Setup Assistant will inform you that an update will be installed. If you select Update the update will be installed immediately.

Figure 1: The welcome screen shown if the Setup Program detects an older version of the Smart Client

Figure 2: The progress screen

Figure 3: Screen shown after successfully installing a new version of the Smart Client.


Uninstall

Last edited: 10/5/2017 11:51:44 AM

Following chapters explain how to uninstall the various tiers of the Redbex redbex software system.


Application Server Database

Last edited: 10/5/2017 11:51:02 AM

The Application Server Database can be deleted by using the SQL Server Management Software of your choice. The Application Server Database is not registered with the Windows Installer and can therefore not be removed from the Windows Control Panel.

To completely remove the Application Server Database delete the Database from the Database Server. Additionally you might need to remove the Login from the database Server that was used as the Accessing User for the Application Server Database.

Figure 1 shows the context menu

Listing 1 shows the SQL commands you can use to uninstall the Application Server Database.

USE [master];

EXEC msdb.dbo.sp_delete_database_backuphistory @database_name = N'<your database's name>;'

GO

DROP DATABASE [<Your database's name>];

GO

DROP LOGIN [<Login name of the accessing user>];

Listing 1: SQL commands to completely remove a Redbex Application Server Database

Note: The Application Server Database includes most of the data you manage with Redbex. Deleting the database will destroy all this data. Be sure that you really do not need the data any more or you have a valid Backup before deleting the application Server Database.


Application Server

Last edited: 10/5/2017 11:51:02 AM

Uninstalling the Application Server can be easily done using the standard Windows procedure for uninstalling software. Note that the windows uninstall procedure differs slightly with different versions of Windows.

Open Programs and Features (figure 1) by clicking the Start button Picture of the Start button, clicking Control Panel, clicking Programs, and then clicking Programs and Features. Alternatively type appwiz.cpl in the Windows Run dialogue or in the start menu's search box and hit Enter.

Select Redbex Application Server, and then click Uninstall on the toolbar or select Uninstall from the context menu (figure 1). If you're prompted for an administrator password or confirmation, type the password or provide confirmation.

Uninstalling will automatically stop the all currently running instances of the Application Server Service. All configuration settings (instance configuration files) will be deleted when uninstalling the Application Server. Make sure to backup the configuration files before uninstalling the Application Server.

Figure 1: The Windows control panel for Programs and Features. From here you can uninstall the Application Server.

Files generated by the Application Server in the Binary storage, Caches, Log or Temporary directory (see chapter Directory Environment for details) will not be deleted when uninstalling the application Server. To perform a totally clean uninstall you will have to remove these directories and all of their contents manually.

Note: files in these directories might include valuable data. Make sure you do not need these files any more or you have a backup of these files before deleting them.

Further reading

Uninstalling software in Windows 7: http://goo.gl/BSDGMA

Uninstalling software in Windows Vista: http://goo.gl/NVbSe3


Application Server Instance

Last edited: 10/5/2017 11:51:02 AM

Additional Application Server instances that were installed with the Application Server Instance Setup Program are not registered with the Windows Installer and can therefore not be uninstalled from using the Windows Installer (the primary instance of the Application Server is removed by the Application Server Setup Program.)

To remove an additional instance of the Application Server you need Administrative rights on the computer the Application Server Instance is installed. Following steps are necessary to completely remove an Application Server Instance

Remove the Windows Service

Step 1: To remove a the Windows Service for the Application Server Instance you have to know the service name. The service names for Application Server services always conform to following patternrbAppSrv_<InstanceIdentifier>. You can determine the service name by using the Windows Service Management Console. Figure 1:1 shows where the service name is displayed, when opening the properties of the service from the Windows Service Management Console.

Figure 1: Details of an installed Application Server Installed as displayed by the Windows Service Management console.

Step 2: Stop the windows Service for the Application Server Instance you want to uninstall. You can again accomplish this by using the Windows Service Management Console.

Step 3: To remove the Windows Service for the Application Server instance you want to uninstall you have to use the Windows command line tool sc.exe

sc delete <Service Name>

Remove directory environment

Each instance of the Application Server has its own directory environment. If you want to remove an instance of the Application Server totally you should delete those files and directories by hand. The used directories can be found by taking a look at the instance configuration file.

Note that removing the binary storage directory fill destroy data. Make sure to have a backup if you plan to reinstall the Application Server.

Remove the instance configuration file

The Application Server Instance Setup Program installs the instance configuration file in the Windows Program folders directory under Redbex\Application Server - <instance identifier>. Remove this directory.


Smart Client

Last edited: 10/5/2017 11:51:40 AM

Uninstalling the Smart Client can be easily done using the standard windows procedure for uninstalling software.

Open Programs and Features by clicking the Start button Picture of the Start button, clicking Control Panel, clicking Programs, and then clicking Programs and Features. Alternatively type appwiz.cpl in the windows run dialogue or in the start menu's search box and hit Enter.

Select Redbex Smart Client, and then click Uninstall or select Uninstall from the context menu (figure 1). If you're prompted for an administrator password or confirmation, type the password or provide confirmation.

Files generated by the Smart Client in the Roaming application data directory, Local application data directory, Log files directory, Downloads directory or Temporary directory (see chapter Directory environment for details) will not be deleted when uninstalling.

Figure 1: Uninstalling the Smart Client from The Windows Control panel.


Smart Client Light

Last edited: 10/5/2017 11:51:40 AM

The Light version of the Smart Client is not registered with the Windows Installer Framwork and can therefore not be uninstalled from Programs and Features (This is the tradeoff for being able to install without Administrative permissions in Windows).

To uninstall the Smart Client you should perform following Actions:

·Delete the Smart Client Light Application Folder: The Smart Client is installed to the LocalApplicationData folder of the user who runs the installation. This is usually a folder like: C:\Users\<username>\AppData\Local\redbex\Smart Client\Light. You can just delete this folder and all of its contents.

·Delete the desktop icon: The Smart Client Light Setup Program will create a link to the Smart Client executable on your Windows desktop.

·Delete the Start menu entries: The Smart Client Light Setup Program creates several entries in your Windows Start Menu. You can just delete these entries.

·Remove File associations


Smart Client Portable

Last edited: 10/5/2017 11:51:40 AM

The Portable version of the Smart Client is not registered with the Windows Installer Framwork and can therefore not be uninstalled from Programs and Features (This is the tradeoff for being able to install without Administrative permissions in Windows).

The Portable version of the Smart Client can be 'uninstalled' by simply deleting the directory where the Smart Client was installed to. By default this is a subdirectory of the LocalApplicationData of the windows user who installed the Portable Smart Client e.g. C:\Users\<username>\AppData\Local\redbex\Smart Client\Portableß1.3.14146.14188\.


Backup

Last edited: 10/5/2017 11:51:06 AM

Before you begin implementing your backup strategy you need to understand what you are trying to protect, how much data you need to recover and also whether the data can be recreated easily or not.

To get started you need to ask yourself a few questions such as the following:

·How much data can be accepted to get lost? A day, one hour, a week, none...?

·Can the data managed by Redbex be easily recreated if there is a failure or it is not the only source of this data? (e.g. is data imported by external files, which are created by third party software?)

·How long can you take the system offline for recovery?

Unfortunately there is nothing like a 'one size fits all' backup strategy, it really depends on your specific environment.

It would go far beyond the scope of this Reference Manual to describe pros and cons of different backup strategies, however following chapters provide information needed to set up a proper backup strategy for all data managed by the components of the Redbex system.


What to backup

Last edited: 10/5/2017 11:51:02 AM

Application Server Database

Most valuable data managed by the Application Server is persisted in the Application Server Database. Therefore a backup and recovery plan for the Application Server Database that meets your business requirements is very important.

Files on the Application Server

While most data handled by the Application Server is stored in the Application Server database there is some data that is stored on the file system. Table one describes the data stored on the file system that should be backed up.

Data | Description
Binary data directory | Binary data (usually files) are not stored in a database but on the file system. Backing up the files in the binary data folder is therefore mandatory.
Configuration files | Usually all the data stored in configuration files is easily recreated. However it might save time if you backup the configuration files.

Table 1: Data to backup on the computer running the Application Server

Binary data stored in the binary data directory is linked by records in the Application Server Database. It is therefore crucial that the backup of the Application Server Database is consistent. We therefore recommend to backup the binary data folder immediately after backing up the Application Server Database. For a successful recovery you must be able to match the backup of the database with the right backup of the binary data directory directory.

When planning your backup note that - depending on your usage - the binary data directory can contain huge amounts of data!


Application Server Database Backup

Last edited: 10/5/2017 11:51:34 AM

The purpose of creating SQL Server backups is to enable you to recover a damaged Application Server database. However, backing up and restoring data must be customized to a particular environment and must work with the available resources. Therefore, a reliable use of backup and restore for recovery requires a backup and restore strategy. A well-designed backup and restore strategy maximizes data availability and minimizes data loss, while considering your particular business requirements.

A backup and restore strategy contains a backup portion and a restore portion. The backup part of the strategy defines the type and frequency of backups, the nature and speed of the hardware that is required for them, how backups are to be tested, and where and how backup media is to be stored (including security considerations). The restore part of the strategy defines who is responsible for performing restores and how restores should be performed to meet your goals for availability of the database and for minimizing data loss. We recommend that you document your backup and restore procedures and keep a copy of the documentation in your run book.

Designing an effective backup and restore strategy requires careful planning, implementation, and testing. Testing is required. You do not have a backup strategy until you have successfully restored backups in all the combinations that are included in your restore strategy. You must consider a variety of factors. These include the following:

·The production goals of your organization for the databases, especially the requirements for availability and protection of data from loss.

·The nature of each of your databases: its size, its usage patterns, the nature of its content, the requirements for its data, and so on.

·Constraints on resources, such as: hardware, personnel, space for storing backup media, the physical security of the stored media, and so on.

Giving a thorough description of all the options you have for backup and recovery of databases on a Microsoft SQL Server would go far beyond the scope of this manual. Additionally thorough recovery planning will also touch hardware issues and security issues. Consistent with the flexibility found in other areas of SQL Server, there are multiple ways to perform a backup, each suited to a different purpose.

There are dozens of good SQL Server books and online resources that explore every detail of backup and recovery - if you plan to store valuable data in the Application Server Database you should really dig into one of them. A good starting point is Microsofts MSDN chapter about backup and restore of SQL Server Databases.


Binary directory backup

Last edited: 10/5/2017 11:51:06 AM

Binary data stored in the binary data directory is linked by records in the Application Server Database. It is therefore crucial that the backup of the Application Server Database is consistent. We therefore recommend to backup the binary data folder immediately after backing up the Application Server Database. For a successful recovery you must be able to match the backup of the database with the right backup of the binary data directory directory.

When planning your backup note that - depending on your usage - the binary data directory can contain huge amounts of data!


%Text%

Navigation: Administrator's manual >

Firewall configuration

Last edited: 10/5/2017 11:51:18 AM

Firewall systems help prevent unauthorized access to computer resources. If any part of the Redbex software system is behind a firewall (and we suggest it should be) you have do define rules to allow specific traffic through that firewall. This chapter only discusses Paket-Filtering Firewalls, additional configuration might be necessary for stateful firewalls and, Proxy-Firewalls.


%Text%

Navigation: Administrator's manual > Firewall configuration >

Application Server

Last edited: 10/5/2017 11:51:20 AM

While the biggest part of the communication with the Application Server is incoming traffic from the Clients there are also other connections that must or shall be allowed. Table 1 summarizes the connections and

Connection

Mandatory

Firewall settings

Connection To Redbex Application Server Database

The Application Server needs a connection to the Application Server Database. Your firewall needs to be configured to allow those connections. The actual configuration needed depends on your SQL Server Network Configuration. E.g. if your SQL server uses TCP/IP the default port.

Please refer to the Sql Server Documentation for more details.

Incoming connections from Redbex Clients

Clients to the Redbex Application Server must be able to connect to the application server using the communication protocol defined during installation (i.e. in your instance configuration).

Open the configured ports for incoming traffic. See chapter Step 7: Web service configuration for the default ports suggested by the installer.

Outgoing connections to the Redbex Distribution Server

The Application Server needs connection to Pöyry Infra GmbH's Redbex Distribution Server to download product updates, licenses, etc.

Configure your firewall to all outgoing TCP connections to distribution.redbex.com (137.117.204.95) on port 80.

Outgoing SMTP connections

The Redbex Application Server needs access to an SMTP server in order to send emails. Since the access data for new users is sent via email access to an SMTP server is mandatory (if you have more than one user in your installation)

Allow all outgoing SMTP connections to the SMTP Server you want to use (as configured in the global settings)

Outgoing FTP

The Application Server can load data from FTP servers and can store data to FTP servers.

If you plan this functionality you will have to configure the firewall to allow outgoing connections to the used FTP servers.

Google Maps API

For creating map views with Google Maps background images Redbex accesses the Google Maps Static API.

If you want to use this functionality you will have to open your firewall

Bing Maps API

For creating map views with Microsoft Bing Maps background images Redbex accesses the Microsoft Bing Maps API.

For creating map views with Google Maps background images Redbex accesses the Microsoft Bing Maps API.

twilio.com

Redbex uses the Twilio API. In order to be able to send SMS from Redbex this API must be accessible.

The twilio service is hosted in Amzon's Elastic Cloud. You need to ensure that your firewall allows outgoing UDP and associated return traffic to any IP address in Amazon’s published range of public IPs.

For more details see:

https://www.twilio.com/help/faq/twilio-client/what-are-twilio-clients-network-connectivity-requirements

Log Entries

Redbex supports logging to the cloud based log service logentries.com. To use this functionality the Application Server must be allowed to communicate with the API of this service.

For this ports 80,514, 443, 10000 and 20000 shall be opened outgoing for following IP addresses:

46.51.172.0

54.247.179.233

46.137.78.79

54.217.226.43

54.217.226.19

54.217.226.25

WMS, WFS Services

The Redbex Application Server can make use of WMS (Web Map Services) and WFS (Web Feature Services).

To access these services the appropriate Connections must be allowed.

Table 1: Summary of Internet connections of the Application Server.


%Text%

Navigation: Administrator's manual > Firewall configuration >

Application Server Database

Last edited: 10/5/2017 11:51:18 AM

The Redbex Application Server Database must be accessible from the Redbex Application Server. The actually needed firewall settings depend on the specific configuration of your SQL Server.

Please refer to Configure the Windows Firewall to Allow SQL Server Access on MSDN for more details.


%Text%

Navigation: Administrator's manual > Firewall configuration >

Smart Client

Last edited: 10/5/2017 11:51:40 AM

Most data transfer initiated by the Smart Client is Data Transfer to the Redbex Application Server. Besides that there are some other online services the Smart Client need access to. Table 1 summarizes the Firewall requirements for the Smart Client.

Connection

Mandatory

Firewall settings

Outgoing connections to the Redbex Application Server

The Smart Client must be able to connect to the Redbex Application Server.

The protocols and ports used for this connection are defined in the Application Server's instance configuration.

Outgoing connections to the Redbex Distribution Server

The Smart Client needs connection to Pöyry Infra GmbH's Redbex Distribution Server to download product updates.

Configure your firewall to all outgoing TCP connections to distribution.redbex.com (137.117.204.95) on port 80.

Google Maps API

For creating map views with Google Maps background images the Smart Client accesses the Google Maps Static API directly.

If you want to use this functionality you will have to open your firewall

Bing Maps API

For creating map views with Microsoft Bing Maps background images the Smart Client accesses the Microsoft Bing Maps API directly.

Open Street Maps API

For creating map views with Open Street Maps background tile the Smart Client accesses the Open Stree Maps API.

Log Entries

The Redbex Smart Client supports logging to the cloud based log service logentries.com (by default the Smart Client is also configured to use that service).

To use this functionality the Application Server must be allowed to communicate with the API of this service.

For this ports 80,514, 443, 10000 and 20000 shall be opened outgoing for following IP addresses:

46.51.172.0

54.247.179.233

46.137.78.79

54.217.226.43

54.217.226.19

54.217.226.25

WMS, WFS Services

When rendering map templates that are configured to use WMS or WFS Services the Smart Client will directly access those services.

To access these services the appropriate Connections must be allowed.


%Text%

Navigation: Administrator's manual >

Certificates

Last edited: 1/22/2018 9:14:06 AM

When accessing the Redbex Application Server via HTTPS the Server (e.g. via MappRover) must have a valid certificate bound to the port where the HTTPS service is provided (usually 443). The clients accessing the Redbex Service will get this certificate and will check if they can trust this certificate. They do this by checking the certificate chain of this certificate, therefore the certificate chain must include a certification authority that is a trusted certification authority for the client accessing the Redbex Service.

For iOS clients you can find a list of trusted root certificates at https://support.apple.com/en-us/HT207177


%Text%

Navigation: Administrator's manual > Certificates >

Using a self signed certificate

Last edited: 10/5/2017 11:51:44 AM

Warning: Self signed certificates are only useful under specific circumstances, e.g. when testing in new environments. Self signed certificates should never be used in production environments!

Self signed certificates can be created with the makecert.exe utility that is part of the Windows SDK (which is automatically installed if you have Visual Studio but can also be manually downloaded from Microsoft). makecert.exe can usually be found in C:\Program Files (x86)\Windows Kits\8.1\bin\x64\makecert.exe.

For managing certificates in Windows use the Microsoft Management Console (mmc.exe) with the Certificates Snap-In.

Step 1: Create a certificate authority certificate

Run cmd.exe as Administrator and use following command line to create a certificate for your own root certification authority:

makecert -sv SignRoot.pvk -cy authority -r signroot.cer -a sha1 -n "CN=Redbex Developer Authority" -ss my -sr localmachine

Make sure you remember the passwords for which you are prompted. Replace the CN= with your preferred name for the root certification authority.

Open the Window's Management Console. Add the Certificate Snap-In for the local machine. The just created certificate can be found under Personal > Certificates

Using Drag&Drop move that certificate to Trusted Root Certification Authorities > Certificates

At this point you have created and installed your own trusted root certification authority.

Step 2: Create a certificate signed by that root authority

Run cmd.exe as Administrator and use following command line to create a certificate signed by the root certification authority we created above:

makecert -iv SignRoot.pvk -ic signroot.cer -cy end -pe -n CN="localhost" -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

Make sure that the CN= matches the DNS name actually used by clients to connect to the server e.g. myserver.mydomain.com

Open the Window's Management Console (mmc.exe). Add the Certificate Snap-In for local machine.

The newly created certificate can be found in Personal > Certificates

Now we need to get the thumbprint of the certificate. Double click the certificate in the MMC. In the certificate window go to the details tab. get the value of the Thumbprint field there. Copy it to notepad and remove all spaces.

Step 3: Binding the certificate to a port

Windows must know which certificate to use when it gets a HTTPS request on a specific port. Binding a certificate to a port is done with the command line tool netsh.exe, you must run netsh.exe as Administrator.

netsh http add sslcert ipport=0.0.0.0:443 certhash=‎8fe8113bc8675339cf415849e6748123621a172 appid={00000000-0000-0000-0000-000000000000}

If you want to unbind the certificate from the port at a later time (e.g. when removing the test certificate and installing a new certificate you can use following command line:

netsh http delete sslcert ipport=0.0.0.0:443

For certhash use the thumbprint of the certificate. Make sure you bind to the right port (usually 443)


%Text%

Navigation: Administrator's manual > Certificates >

Using a signed certificate

Last edited: 10/5/2017 11:51:44 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


%Text%

Navigation: Administrator's manual > Certificates >

Using a CACert signed certificate

Last edited: 10/5/2017 11:51:44 AM

CAcert.org is a community driven Certificate Authority that issues certificates to the public at large for free.

Prerequisites

To get certificates you have to be a member of CACert.org (membership is free)

To issue certificates for a specific domain you must be owner of that domain. CACert checks this by seinding an email to specific email addresses in this domain e.g. root@mydomain.com. Therefore you must be able to configure email delivery for that domain.

Crating a CSR (Certificate Signing Request) for your server

A CSR or Certificate Signing request is a block of encoded text that is given to a Certificate Authority when applying for an SSL Certificate. Creating a CSR can be done with different tools. https://www.digicert.com provides the free DigiCert® Certificate Utility for Windows which is extremly easy to use and well documented.

Run this tool on the server for which you want to create the certificate.

This tool will create the CSR as text block that can be used on CACert.org to create a domain certificate.

Installing the certificate issued by CACert

Use the CSR on CACert.org to create a certificate.

CACert.org will issue domain certificates in PEM format (an ASCII format). Save that to a file.

On your server. Open the Window's Management Console (mmc.exe). Add the Certificate Snap-In for local machine. Go to Personal > Certificates right click the Certificates node and choose All Tasks > Import select the crt file and import it.

Now you have installed the certificate for your server.

Installing the CACert.org root authority on all clients

CACert.org is usually not by default a trusted root certification authority on computers that access the Redbex Server. You will therefore have to install the CACert.org certificate manually on every client. On CACert.org you can download the root certificate in different formats and then install it on your client(s)


Tips for Windows administration

Last edited: 10/5/2017 11:51:44 AM

Following chapters provide a quick reference to some operating system administration tasks you might need for administrating the Application Server the Application Server Database and the Smart Client.


Managing Windows Services

Last edited: 10/5/2017 11:51:46 AM

Each Redbex Application Server Instance is installed as a separate Windows Service.

A Windows Service is an advanced component/feature of Microsoft Windows that supports the management of long running, background processes and applications.

Unlike regular programs that are started by a user and run only while that user is logged on, a Windows Service application can start before any user logs on and can continue to run even after all users have logged off.

Following chapters give some basic information on how to manage these services.


Windows Service control panel

Last edited: 10/5/2017 11:51:46 AM

Windows Services can be managed using the Windows Services control panel applet.

The Windows Services control panel is a graphical user interface that allows to view and manage the installed Windows Services, and therefore also the Services for each instance of the Application Server installed on that machine.

To start the Windows Services control panel perform one of the following

·Run services.msc from the command line

·Windows Vista to Windows 7: Click Start, click Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-click Services

When started the Windows Service control panel lists all Services installed on the current computer. Double-click an entry to reveal its specific properties.

You can start, stop, pause or resume the service as appropriate. You can also modify the settings, such as the startup type (Automatic or Manual) or the log on account (on the Log On tab), etc.

Figure 1: The Windows Services control panel

Figure 2: Details for a selected Windows Service


Starting and stopping Windows Services

Last edited: 10/5/2017 11:51:42 AM

To start or stop a Windows Service, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure.

You can use the Windows Services control panel, the net command or the sc command to start and stop windows services.

To start and stop a Windows Service using the net command open Command Prompt and use following commands:

·To start a service, type: net start "<service name>"

·To stop a service, type: net stop "<service name>"

The Application Server services are named rbAppSrv_<instance Identifier> , where <instance Identifier> is the instance identification string you chose on installation of the Application Server or an additional Application Server instance.


Changing startup type

Last edited: 10/5/2017 11:51:42 AM

The Redbex Application Server Service are configured to start automatically when the Windows boots. However you can change the startup type according to your needs by using the Windows Service control panel or by using the command line with the command sc.

Start type | Description
Automatic | The service will be started during the boot process of Windows
Automatic (Delayed start) | Only available Windows Vista or Windows Server 2008 or later. The service will be started during the boot process of Windows but only after 2 minutes (configurable value) after the last Automatic service has started.
Manual | The service will not be started when Windows boots. The service will only start on demand, when explicitly requested to do so by a user (or by an application). This is the appropriate choice when you want to start and stop the service yourself.
Disabled | The service will not be started when Windows boots. The service can not be started by any user or program. Choose this option to totally disallow the service from running.

Table 1: Startup types for Windows Services


Creating a local Windows user

Last edited: 10/5/2017 11:51:12 AM

Following procedure describes hot to create a local Windows user account. This procedure applies to: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012. Administrators is the minimum group membership required to complete this procedure.

To create a local user account execute following steps:

Open Local Users and Groups: Either go to Computer Management\System Tools\Local Users and choose Groups\Users or run lusrmgr.msc from the command line.

·In the console tree right click on Users

·Select New User from the context menu. The New User dialogue will be shown (see figure 1).

·Type the appropriate information in the dialog box.

·Click Create, and then click Close .

To perform this procedure, you must provide credentials for the Administrator account on the local computer (if you are prompted), or you must be a member of the Administrators group on the local computer.

A user name cannot be identical to any other user name or group name on the computer that is being administered. The user name can contain up to 20 uppercase characters or lowercase characters, except for the following:

" / \ [ ] : ; | = , + * ? < > @

A user name cannot consist solely of periods (.) or spaces. In Password and Confirm password , you can type a password containing up to 127 characters.

Figure 1: The New user dialogue


%Text%

Navigation: Administrator's manual > Tips for Windows administration >

Configuring Namespace Reservations

Last edited: 10/5/2017 11:51:22 AM

The Redbex Application Server can communicate with clients communicate over HTTP and HTTPS. For this it is necessary that the user running the Application Server must have the access rights for that a portion of the HTTP URL namespace that used by the Redbex Application Server.

These access rights are usually configured by the Redbex Application Server Setup Program. If you manually configure or re-configure your installation of the Redbex Application Server (e.g. if you want the service to be provided on a different port or if you change the instance name) you will have to manually configure these access rights with so called namespace reservations.

The Windows command-line tool netsh.exe can be used to configure namespace reservations.

Namespace reservation assigns the rights for a portion of the HTTP URL namespace to a particular group of users. In addition a namespace reservation will modify the Windows routing database that is used to determine which application receives an incoming HTTP / HTTPS request. This way it is also possible that multiple services can use the same port (e.g. Redbex Application Server and IIS).

This manual does not provide a complete documentation on how to use netsh or how to build your HTTPS routing table, but in the following you find some examples that should get you started. For more information refer to Microsoft's MSDN documentation

Basic syntax

netsh http add urlacl url=http://+:80/<InstanceName> user=<WindowsUser>

the url= parameter defines which urls will be reserved. The + is a wildcard that will match any dns name or ip address. For more information on wildcards see Routing Incoming Requests on MSDN.

The InstanceName is the instance name of your Application Server.

The user parameter specifies the Windows user that runs the Redbex Application Server this can be a local Windows user or an Active Directory user.

Examples

netsh http add urlacl url=http://+:80/Instance01 user=RedbexService

netsh http add urlacl url=https://+:443/Instance01 user="ad\RedbexService"

netsh http add urlacl url=http://redbex.mydomain.com:80/Instance01 user=.\RedbexService


Adding a local user to a group

Last edited: 10/5/2017 11:51:02 AM

Open Local Users and Groups: Either go to Computer Management\System Tools\Local Users and choose Groups\Users or run lusrmgr.msc from the command line.

·In the console tree right click on Users

·Right click the user you want to add into a group, and then click Properties (figure 1:1)

·Go to the Member of tab (figure 1:2)

·Click on Add (figure 1:3), and then type the name of the user group e.g. Performance Monitor Users .(figure 1:4)

·Click OK, and then click OK again.

Figure 1: Adding a local user to a local user group in Windows 2008 R2


Event viewer

Last edited: 10/5/2017 11:51:14 AM

The Application Server as Well as the Smart Client use the Windows Event log to log important events. You can use the Windows Event Viewer to see those events.

To start the Windows event viewer type eventvwr.msc on the command line or in the search field.

The Application Server logs to the Windows Application Event Log and uses the Event Log Source RedbexApplicationServer , the Smart Client uses the Event Log Source RedbexSmartClient.

To see all entries created by the Application Server you can create a custom view that filters for that source. For that go to to the Action menu and select Create Custom View .

Figure 1 shows the definition of a custom view.

Figure 1: Definition of a custom view in the Windows Event viewer to filter for all entries created by the Application Server


Region and Language

Last edited: 10/5/2017 11:51:34 AM

The Region and Language dialogue is used to show and modify settings that are also used by the Redbex Smart Client.

To start the Region and Language dialogue type intl.cpl on the command line or in the search field. With this dialogue you can change how date, time and numbers will be presented.

Figure 1: The Region and Language Dialogue


Distribution Server

Last edited: 11/8/2017 9:32:32 AM

The Distribution Server is a server hosted by Pöyry Infra GmbH. It provides several services to Application Server and Smart Client installations e.g. distribution of Smart Client updates, distribution of Modular Updates and Licensing.

For Smart Client Installations the Distribution Server provides a service that allows Smart Clients to check for new versions. If a new version is found the Distribution Server will tell the requesting Smart Client the URL where the update to the new version can be loaded. The Update check is performed by the Smart Client on request of the user. The Distribution Server will only deliver updates that have the same Application Server compatibility version as the already installed Smart Client, therefore an update will never break the version compatibility.

The Distribution Server provides several services for Application Server installations subsumed under the term Modular updates. The data for this modular updates is provided by the Distribution Server.


Appendices

Last edited: 10/5/2017 11:51:02 AM


Feature types

Last edited: 10/5/2017 11:51:20 AM

This part of the Reference Manual documents all feature types currently supported by Redbex. Note all characteristics of feature types (name, description, path, etc.) are translated into all languages supported by the Application Server. This documentation lists names in English only.

Properties in the property structures for type specific feature data and type specific observation data have a unique identifying name that is used mainly for data import and data export. In the following chapters this identifying name is shown with each property.

Feature types are structured in a feature types tree, that is created from the feature type path that is hard coded within each feature types. The following chapters and sub-chapters reflect this structure.


Document management

Last edited: 10/5/2017 11:51:20 AM

With just a few feature types Redbex implements a versatile way of managing arbitrary documents. It might seem a far shot at first but when you think of it in detail, its just a proof that the concept of features and observations together with feature relations is really strong.


Document

Last edited: 10/5/2017 11:51:18 AM

A document is a piece of digitized human knowledge in several versions. I.e. a document can have more than one file, each file representing a different version of the document.

Characteristic | Note
Name | Document
Path | \Document management
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection Identifier | Description
Keywords KEYWORDS | Keywords for this document Property type: Text Default Value: null Validation rule: Length <= 4000 Display Options: multi-line = true
Authors AUTHORS | Authors of the document Property type: Text Default Value: null Validation rule: Length <= 4000 Display Options: multi-line = true

Table 1: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

Property, Property Collection Identification | Description
File FILE | Stores a arbitrary binary file Property type: Binary Default Value: null Validation rule: Display Options:
Change history CHANGE_HISTORY | Document change history Property type: Text Default Value: null Validation rule: Length <= 4000 Display Options: multi-line = true
Authors AUTHORS | Authors of the document Property type: Text Default Value: null Validation rule: Length <= 4000 Display Options: multi-line = true

Table 2: Properties and collections of the type specific observation data property structure


Document folder

Last edited: 10/5/2017 11:51:18 AM

A Document Folder is a platform feature that can contain other document folders or documents.

Characteristic | Note
Name | Document folder
Path | \Document management
Feature type icon |
Feature type class | Platform
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | Document folder, Document

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for extended observation


%Text%

Navigation: Appendices > Feature types >

Environment

Last edited: 10/5/2017 11:51:20 AM

Feature types in this path are used for representing various environmental phenomena, they can be used in many different application domains.


Air quality

Last edited: 10/5/2017 11:51:02 AM

Represents the qulaity of the air in terms of particles and Nox.

Characteristic | Note
Name | Meteorological Situation
Path | \Environment
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | Projected, Geographic
Allowed geometries | Point
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Particle content ParticleContent | Value that represents the number of particles in the air Property type: Numeric Default Value: null Display Unit: µg/m3 Validation rule: none Display Options: Decimals: 2
NOx Nox | Amount of Nitrogen Oxides Property type: Numeric Default Value: null Display Unit: µg/m3 Validation rule: none Display Options: Decimals: 2


%Text%

Navigation: Appendices > Feature types > Environment >

Meteorological situation

Last edited: 10/5/2017 11:51:20 AM

This feature type is used to represent some key characteristics of the meteorological situation at a specific point. Meteorological parameters are usually parameters that are measured over intervals of time, e.g. the amount of precipitation on a square meter in the last 24 hours. The time span for which a single observation of this feature type is valid is to be interpreted by the user.

Characteristic | Note
Name | Meteorological Situation
Path | \Environment
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | Projected, Geographic
Allowed geometries | Point
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Mean sea level pressure MSLP | Mean sea level pressure (MSLP) is the atmospheric pressure at sea level or (when measured at a given elevation on land) the station pressure reduced to sea level assuming an isothermal layer at the station temperature. Property type: Numeric Default Value: null Display Unit: hPa Validation rule: Value ≥ 850 and ≤ 1100 Display Options: Decimals: 1
Pressure PRESSURE | The atmospheric pressure measured at the point of observation. Property type: Numeric Default Value: null Display Unit: hPa Validation rule: Value ≥ 850 and ≤ 1100 Display Options: Decimals: 1
Temperature TEMPERATURE | The thermodynamic temperature of the air. Property type: Numeric Default Value: null Display Unit: °C Validation rule: Value ≥ -90 and ≤ 60 Display Options: Decimals: 1
Precipitation PRECIPITATION | Precipitation is any product of the condensation of atmospheric water vapor that falls under gravity. This property is used for recording the amount of precipitation. Property type: Numeric Default Value: null Display Unit: l/m² (equal to mm) Validation rule: Value ≥ 0 and ≤ 2000 Display Options: Decimals: 1

Table 2: Properties and collections of the type specific observation data property structure


Pore air analysis

Last edited: 10/5/2017 11:51:20 AM

This feature type represents the result of a laboratory analysis. The structure of this feature type is mainly influenced by the Interlab data format.

Characteristic | Note
Name | Water analysis
Path | \Environment
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A
Single observation | No

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection | Description
Analysis class ANALYSISCLASS Interlab: REGISTERTYP | Can be used to classify different basic types of analyses. Classification of type Laboratory Analysis Class
Analysis reason ANALYSISREASON Interlab: PROVTAGNINGSORSAK | Classification of type Laboratory Analysis Reason
Assessment comment ASSESSMENTCOMMENT Interlab: KOMMENTAR | Comment on the assessment of water quality. Property Type: Text Default Value: none Display Options: none
Chemical assessment CHEMICALASSESSMENT Interlab: KEMISK BEDÖMNING | Classification of type Quality assessment Assessment of the water quality with regard to the analysis of chemical parameters.
Analysis results ANALYSISRESULTS | Collection of analysis results. See table 3 for details.
Client Address CLIENTADDRESS Interlab: ADRESS | Address of the client for whom the analysis was done Property Type: Text Default Value: none Display Options: none
Client City CLIENTCITY Interlab: ORT | City of the client for whom the analysis was done Property Type: Text Default Value: none Display Options: none
Client municipality code CLIENTMINICIPALITYCODE Interlab: KOMMUNKOD | ID or code fo the municipality for which the analysis was done Property Type: Text Default Value: none Display Options: none
Client Name CLIENTNAME Interlab: NAMN | Name of the client for whom the analysis was done. Property Type: Text Default Value: none Display Options: none
Client Zip Code CLIENTZIPCODE Interlab: POSTNR | ZIP code of the client for whom the analysis was done Property Type: Text Default Value: none Display Options: none
Laboratory LABORATORY Interlab: LABORATORIUM | Name of the laboratory that analyzed the sample. Property Type: Text Default Value: none Display Options: none
Microbiological assessment MICROBIOLOGICALASSESSMENT Interlab: MIKROBIOLOGISK BEDÖMNING | Classification of type Quality assessment Assessment of the water quality with regard to the analysis of microbiological parameters.
Overall assessment OVERALLASSESSMENT Interlab: BEDÖMNING | Comments in relation to the assessment Property Type: Text Default Value: none Display Options: none
Probe site ID PROBESITEID Interlab: PROVPLATSID | ID of the location where the samples are taken Property Type: Text Default Value: none Display Options: none
Probe site name PROBESITENAME Interlab: PROVPLATSNAMN | Name of the location where the samples are taken Property Type: Text Default Value: none Display Options: none
Project name PROJECTNAME Interlab: PROJEKT | Name of the project for which the analysis was done Property Type: Text Default Value: none Display Options: none
Sampling specification SAMPLINGSPECIFICATION Interlab: PROVTYPSPECIFIKATION | Property Type: Text Default Value: none Display Options: none
Sampler SAMPLER Interlab: PROVTAGARE | Name of the Person who took the analyzed sample. Property Type: Text Default Value: none Display Options: none
Sampling type SAMPLINGTYPE Interlab: PROVTYP | Classification of type Water analysis sampling type

Table 2: Properties and collections of the type specific observation data property structure on level 0

Property | Description
Accuracy ACCURACY Interlab: MÄTOSÄCKERHET | Specification of the accuracy of the analysis result for this parameter Property Type: Text Default Value: none Display Options: none
Detection limit DETECTIONLIMIT Interlb: DETEKTIONSGRÄNS | Value above which the analyzed Parameter can be detected Property Type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 4 Display unit: empty
Method METHOD Interlab: METHODBEDECKNING | Method used to derive a value for a specific parameter. E.g. name of standard. Property Type: Text Default Value: none Display Options: none
Numeric Value NUMERICVALUE Interlab: MÄTVERDETAL | If the analysis result is a numerical value this value is persisted in this property Property Type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 4 Display unit: empty
Parameter PARAMETER Interlab: PARAMETER | Parameter that was analyzed Classification of type Water analysis parameter
Parameter assessment PARAMETERASSESSMENT Interlab: PARAMETERBEDÖMNING | Assessment of the analysis result for this parameter Property Type: Text Default Value: none Display Options: none
Parameter comment PARAMETERCOMMENT Interlab: KOMMENTAR | Comment on the analysis result for this parameter Property Type: Text Default Value: none Display Options: none
Quantification limit QUANTIFICATIONLIMIT Interlab: RAPPORTERINGSGRÄNS | Value above which the analysis result for a parameter can be quantified Property Type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 4 Display unit: empty
Text value TEXTVALUE Interlab: MÄTVERDETEXT | If the analysis result is a textual value this value is persisted in this property Property Type: Text Default Value: none Display Options: none
Trace TRACE Interlab: Mätvärdespår | Property type: Boolean Default value: null
Unit UNIT Interlav: ENHET | Unit of the numerical value Property Type: Text Default Value: none Display Options: none
Value type VALUETYPE Interlab: MÄTVERDETALAMN | Classification of type LaboratoryAnalysisValueType

Table 3: Properties and collections of the type specific observation data property structure for the AnalysisResults collection


General

Last edited: 10/5/2017 11:51:20 AM

Feature types in this path are used for representing fundamental physical phenomena, they can be used in many different application domains.


Distance

Last edited: 10/5/2017 11:51:18 AM

This feature type represents the linear distance between two points.

Characteristic | Note
Name | Distance
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | Point, Line
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Distance DISTANCE | Linear distance between two points Property type: Quantity of type Length Default Value: null Default Unit: m Validation rule: Value ≥ 0 Display Options: Decimals: 5
Temperature TEMPERATURE | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Distance change

Last edited: 10/5/2017 11:51:18 AM

This feature type represents the change of a distance between two points. the main difference to a Distance feature type is that a distance change can also have negative values, whereas a distance is by definition always positive.

Characteristic | Note
Name | Distance change
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | Point, Line
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Distance DISTANCE | Linear distance between two points Property type: Quantity of type Length Default Value: null Default Unit: m Validation rule: Display Options: Decimals: 5
Temperature TEMPERATURE | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5
Zero reading ZERO READING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Elevation

Last edited: 10/5/2017 11:51:18 AM

Represents the elevation of a point expressed in the underlying vertical coordinate system.

Characteristic | Note
Name | Elevation
Path | \Surveying
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | Projected coordinate system
Allowed Geometry types | Point
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection | Description
Elevation | Numeric value expressing the elevation. Expressed in the unit of the underlying vertical coordinate system. Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Zero reading | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Force

Last edited: 10/5/2017 11:51:18 AM

Represents an influence that causes an object to undergo a certain change, either concerning its movement, direction, or geometrical construction together with the thermodynamic temperature.

Characteristic | Note
Name | Force
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Force FORCE | Property type: Quantity of type Force Default Value: null Default Unit: N Validation rule: Value ≥ 0 Display Options: Decimals: 5
Temperature TEMPERATURE | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Pressure

Last edited: 10/5/2017 11:51:20 AM

This feature type represents pressure with temperature

Characteristic | Note
Name | Pressure
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Pressure PRESSURE | Property type: Quantity of type Pressure Default Value: null Default Unit: Pa Validation rule: Value ≥ 0 Display Options: Decimals: 5
Temperature TEMPERATURE | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Region

Last edited: 10/5/2017 11:51:20 AM

Represents a planar region defined in a projected or geographic system bounded by a polygon and including an elevation interval

Characteristic | Note
Name | Projected Region
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | Projected, Geographic
Allowed geometries | Polygon
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Minimum elevation MINELEVATION | If given defines the minimal elevation for the elevation boundary. Expressed in the underlying projected coordinate system's vertical coordinate system. Property Type: Numeric Default Value: none Display Options: Decimal places: 3
Maximum elevation MAXELEVATION | If given defines the maximal elevation for the elevation boundary. Expressed in the underlying projected coordinate system's vertical coordinate system. Property Type: Numeric Default Value: none Display Options: Decimal places: 3

Table 2: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

This feature type has no type specific observation data.


%Text%

Navigation: Appendices > Feature types > General >

Sound level

Last edited: 10/5/2017 11:51:42 AM

Represents the sound level. Does not make presume any specific type of measurement.

Characteristic | Note
Name | Sound level
Path | \Environment
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | Point
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Value Value | Sound level Property type: Numeric Default Value: null Display Unit: dB Validation rule: Value ≥ 0 and ≤ 200 Display Options: Decimals: 3

Table 2: Properties and collections of the type specific observation data property structure


Strain

Last edited: 10/5/2017 11:51:20 AM

A strain is a normalized measure of deformation representing the displacement between particles in the body relative to a reference length.

Characteristic | Note
Name | Strain
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | Point, Line
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Strain STRAIN | Property type: Numeric Default Value: null Validation rule: none Display Options: ·Decimals: 5 ·Display unit: m/m
Temperature TEMPERATURE | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5

Table 2: Properties and collections of the type specific observation data property structure


Temperature

Last edited: 10/5/2017 11:51:20 AM

Represents the thermodynamic temperature of an object.

Characteristic | Note
Name | Temperature
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Temperature TEMPERATURE | Thermodynamic temperature Property Type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: none
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific feature data property structure


Velocity

Last edited: 10/5/2017 11:51:20 AM

Represents the the speed with which an object is moving.

Characteristic | Note
Name | Velocity
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Velocity VELOCITY | Property type: Quantity of type Velocity Default Value: null Default Unit: m/s Validation rule: Value ≥ 0 Display Options: Decimals: 5
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Volume

Last edited: 10/5/2017 11:51:20 AM

Represents the quantity of three-dimensional space enclosed by some closed boundary.

Characteristic | Note
Name | Volume
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Volume VOLUME | Property type: Quantity of type Volume Default Value: null Default Unit: m³ Validation rule: Value ≥ 0 Display Options: Decimals: 5
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Volumetric flow rate

Last edited: 10/5/2017 11:51:20 AM

Represents the volume of fluid passing though a given surface per unit time.

Characteristic | Note
Name | Volumetric flow rate
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Flow rate FLOWRATE | Amount of water delivered Property type: Quantity of type Volume / Time Default Value: null Default Unit: m³ / s Validation rule: Value ≥ 0 Display Options: Decimals: 2
Temperature Temperature | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Generic

Last edited: 10/5/2017 11:51:20 AM

Feature types in this path can be used in many different application domains. They are designed to be used for recording data of different phenomena.


Advanced statistical values

Last edited: 10/5/2017 11:51:20 AM

This feature type is a generic feature type that is used as output feature type of the simple statistic calculation type. This feature type is usually the result of a calculation algorithm.

Characteristic | Note
Name | Statistic simple
Path | \Generic
Feature type icon |
Feature type class | Regular
Spatial data support | No spatial data support
Allowed spatial systems | N/A
Allowed Geometry types | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Minimum MIN | Minimum value of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Maximum MAX | Maximum value of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Mean AVG | Arithmetic mean of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Sum SUM | Sum of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Count CNT | Count of samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Median Med | Median of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Standard deviation Std | Standard deviation of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Modus Mod | Modus of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Lower quantil Q1 | Lower quantil Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Upper quantil 2 Q2 | Upper quantil Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5

Table 2: Properties and collections of the type specific observation data property structure


Axis sections

Last edited: 10/5/2017 11:51:18 AM

This feature type can be used to define named sections on an axis reference system. Features of this type can be used in various algorithms and presentations to evaluate data based on sections of an axis.

Characteristic | Note
Name | Axis sections
Path | \Generic
Feature type icon |
Feature type class | Regular
Spatial data support | Axis
Allowed spatial systems | N/A
Allowed Geometry types | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Figure 1: The structure of the type specific data for this feature type.

Sections

Property, Property Collection Identifier | Description
Section from SEcTION_FROM | ID of the classification element Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 0
Class name SEcTION_TO | The name of the class Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Section type SECTIONTYPE | Classification
Name NAME | Name of the section Property type: String Default Value: null Validation rule: none Display Options: Decimals: 0
Description DESCRTIPTION | Description of the section

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Classification distribution

Last edited: 10/5/2017 11:51:10 AM

This feature type is a generic feature type that is mostly used as output feature type of calculations.

Characteristic | Note
Name | Classification distribution
Path | \Generic
Feature type icon |
Feature type class | Regular
Spatial data support | No spatial data support
Allowed spatial systems | N/A
Allowed Geometry types | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Classification element ID ID | ID of the classification element Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 0
Class name CLASSNAME | The name of the class Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Distribution value DISTRIBUTIONVALUE | The value of the class in the distribution. Unit depends on the context. Property type: String Default Value: Validation rule: Display Options: Single line

Table 2: Properties and collections of the type specific observation data property structure


%Text%

Navigation: Appendices > Feature types > Generic >

Event diary

Last edited: 10/5/2017 11:51:18 AM

This feature type is used to represent a diary of events, i.e. a log of points in time when important actions or conditions where encountered. E.g. when doing vibration monitoring you might want to log points in time when specific events (e.g. excavation works) took place. The event diary can then be used for better interpretation of vibration measurement results.

Characteristic | Note
Name | Event diary
Path | \Generic
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on Feature
Allowed spatial systems | Projected, Geographic, Axis
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Event class EventClass | The type of the event. Used to classify events with different characteristics. Property type: Classification of type Event Class
Name EvnetName | A short descriptive name of the event Property type: Text
Description EVENTDescription | A detailed description of the event Property type: Text Display Options: multiline

Table 2: Properties and collections of the type specific observation data property structure


Generic simple

Last edited: 10/5/2017 11:51:18 AM

This feature type can be used to represent phenomena without observations. This feature type is therefore mostly useful in situations where you want to record the existence of a feature with some associated data.

Characteristic | Note
Name | Generic simple
Path | \Generic
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed Geometry types | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines no property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines no property structure for type specific feature data.


Generic single numeric SSF

Last edited: 10/5/2017 11:51:18 AM

This feature type can be used to represent phenomena where observations result in a single numerical value. Features of this type support spatial data on feature.

Characteristic | Note
Name | Generic single numeric SSF
Path | \Generic
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed Geometry types | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Numeric value GENERICNUMBER | Numeric value Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5

Table 2: Properties and collections of the type specific observation data property structure


Generic single numeric SSO

Last edited: 10/5/2017 11:51:18 AM

This feature type can be used to represent phenomena where observations result in a single numerical value. Features of this type support spatial data on the features observation.

Characteristic | Note
Name | Generic single numeric SSF
Path | \Generic
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on observation
Allowed spatial systems | All
Allowed Geometry types | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Numeric value GENERICNUMBER | Numeric value Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5

Table 2: Properties and collections of the type specific observation data property structure


Group

Last edited: 10/5/2017 11:51:20 AM

This feature type represents simply a group of features. It can be used to group feature of all feature types.

Characteristic | Note
Name | Simple Group
Path | \Generic
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | All

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Measurement round

Navigation: Appendices > Feature types > Generic >

Measurement Group

Last edited: 4/4/2018 10:30:02 AM

This feature type represents a group of features that are usually observer in the same run.

Characteristic | Note
Name | Measurement Group
Path | \Generic
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | All

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Control program

Last edited: 4/4/2018 10:34:40 AM

This feature type represents a group of features that belong to a specific control program.

Characteristic | Note
Name | Control program
Path | \Generic
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | All

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Platform

Last edited: 10/5/2017 11:51:20 AM

This feature type represents simply a platform for other features. It can be used to structure features.

Characteristic | Note
Name | Simple Group
Path | \Generic
Feature type icon |
Feature type class | Platform
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | All

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Simple statistical values

Last edited: 10/5/2017 11:51:20 AM

This feature type is a generic feature type that is used as output feature type of the simple statistic calculation type.

Characteristic | Note
Name | Simple statistical values
Path | \Generic
Feature type icon |
Feature type class | Regular
Spatial data support | No spatial data support
Allowed spatial systems | N/A
Allowed Geometry types | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Minimum MIN | Minimum value of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Maximum MAX | Maximum value of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Mean AVG | Arithmetic mean of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Sum SUM | Sum of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Count CNT | Count of samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5

Table 2: Properties and collections of the type specific observation data property structure


%Text%

Navigation: Appendices > Feature types >

Geology

Last edited: 10/5/2017 11:51:22 AM


%Text%

Navigation: Appendices > Feature types > Geology >

Rock drill hole

Last edited: 10/5/2017 11:51:34 AM

Represents a geological drill hole in a hardrock environment.

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Soil laboratory analysis

Navigation: Appendices > Feature types > Geology >

Water laboratory analysis

Last edited: 10/5/2017 11:51:20 AM

This feature type represents the result of a soil analysis. The structure of this feature type is mainly influenced by the Interlab data format.

Characteristic | Note
Name | Water analysis
Path | \Geology
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A
Single observation | Yes

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection | Description
Analysis class ANALYSISCLASS Interlab: REGISTERTYP | Can be used to classify different basic types of analyses. Classification of type Laboratory Analysis Class
Analysis reason ANALYSISREASON Interlab: PROVTAGNINGSORSAK | Classification of type Laboratory Analysis Reason
Assessment comment ASSESSMENTCOMMENT Interlab: KOMMENTAR | Comment on the assessment of water quality. Property Type: Text Default Value: none Display Options: none
Chemical assessment CHEMICALASSESSMENT Interlab: KEMISK BEDÖMNING | Classification of type Quality assessment Assessment of the water quality with regard to the analysis of chemical parameters.
Analysis results ANALYSISRESULTS | Collection of analysis results. See table 3 for details.
Client Address CLIENTADDRESS Interlab: ADRESS | Address of the client for whom the analysis was done Property Type: Text Default Value: none Display Options: none
Client City CLIENTCITY Interlab: ORT | City of the client for whom the analysis was done Property Type: Text Default Value: none Display Options: none
Client municipality code CLIENTMINICIPALITYCODE Interlab: KOMMUNKOD | ID or code fo the municipality for which the analysis was done Property Type: Text Default Value: none Display Options: none
Client Name CLIENTNAME Interlab: NAMN | Name of the client for whom the analysis was done. Property Type: Text Default Value: none Display Options: none
Client Zip Code CLIENTZIPCODE Interlab: POSTNR | ZIP code of the client for whom the analysis was done Property Type: Text Default Value: none Display Options: none
Laboratory LABORATORY Interlab: LABORATORIUM | Name of the laboratory that analyzed the sample. Property Type: Text Default Value: none Display Options: none
Microbiological assessment MICROBIOLOGICALASSESSMENT Interlab: MIKROBIOLOGISK BEDÖMNING | Classification of type Quality assessment Assessment of the water quality with regard to the analysis of microbiological parameters.
Overall assessment OVERALLASSESSMENT Interlab: BEDÖMNING | Comments in relation to the assessment Property Type: Text Default Value: none Display Options: none
Probe site ID PROBESITEID Interlab: PROVPLATSID | ID of the location where the samples are taken Property Type: Text Default Value: none Display Options: none
Probe site name PROBESITENAME Interlab: PROVPLATSNAMN | Name of the location where the samples are taken Property Type: Text Default Value: none Display Options: none
Project name PROJECTNAME Interlab: PROJEKT | Name of the project for which the analysis was done Property Type: Text Default Value: none Display Options: none
Sampling specification SAMPLINGSPECIFICATION Interlab: PROVTYPSPECIFIKATION | Property Type: Text Default Value: none Display Options: none
Sampler SAMPLER Interlab: PROVTAGARE | Name of the Person who took the analyzed sample. Property Type: Text Default Value: none Display Options: none
Sampling type SAMPLINGTYPE Interlab: PROVTYP | Classification of type Water analysis sampling type

Table 2: Properties and collections of the type specific observation data property structure on level 0

Property | Description
Accuracy ACCURACY Interlab: MÄTOSÄCKERHET | Specification of the accuracy of the analysis result for this parameter Property Type: Text Default Value: none Display Options: none
Detection limit DETECTIONLIMIT Interlb: DETEKTIONSGRÄNS | Value above which the analyzed Parameter can be detected Property Type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 4 Display unit: empty
Method METHOD Interlab: METHODBEDECKNING | Method used to derive a value for a specific parameter. E.g. name of standard. Property Type: Text Default Value: none Display Options: none
Numeric Value NUMERICVALUE Interlab: MÄTVERDETAL | If the analysis result is a numerical value this value is persisted in this property Property Type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 4 Display unit: empty
Parameter PARAMETER Interlab: PARAMETER | Parameter that was analyzed Classification of type Water analysis parameter
Parameter assessment PARAMETERASSESSMENT Interlab: PARAMETERBEDÖMNING | Assessment of the analysis result for this parameter Property Type: Text Default Value: none Display Options: none
Parameter comment PARAMETERCOMMENT Interlab: KOMMENTAR | Comment on the analysis result for this parameter Property Type: Text Default Value: none Display Options: none
Quantification limit QUANTIFICATIONLIMIT Interlab: RAPPORTERINGSGRÄNS | Value above which the analysis result for a parameter can be quantified Property Type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 4 Display unit: empty
Text value TEXTVALUE Interlab: MÄTVERDETEXT | If the analysis result is a textual value this value is persisted in this property Property Type: Text Default Value: none Display Options: none
Trace TRACE Interlab: Mätvärdespår | Property type: Boolean Default value: null
Unit UNIT Interlav: ENHET | Unit of the numerical value Property Type: Text Default Value: none Display Options: none
Value type VALUETYPE Interlab: MÄTVERDETALAMN | Classification of type LaboratoryAnalysisValueType

Table 3: Properties and collections of the type specific observation data property structure for the AnalysisResults collection


Geotechnics

Last edited: 10/5/2017 11:51:20 AM

Feature types in this section are usually used for geotechnical monitoring. Note that many geotechnical observations can be represented by general feature types (see chapter General).


Extensometer

Last edited: 10/5/2017 11:51:18 AM

Represent axial deformation along a straight line.

Characteristic | Note
Name | Extensometer
Path | \Geotechnics
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed Geometry types | Point, line
Allowed contained feature types | N/A

Property structure for type specific feature data

Property, Property Collection | Description
Azimuth | Used in conjunction with Dip (see below) to describe the spatial orientation of the borehole in which the inclinometer is installed. 0 means North direction in the underlying coordinate system. Property type: Numeric Default Value: 0 Validation rule: ≥ 0 and <360 Display Options: Decimals: 0 Unit: ° (Degree)
Dip | Used in conjunction with Azimuth (see above) to describe the spatial orientation of the borehole in which the inclinometer is installed. 0 is horizontal, 90° is perpendicular up, -90 is perpendicular down Default Value: -90 Validation rule: ≥ -90 and ≤ 90 Display Options: Decimals: 0 Unit: ° (Degree)
RodLength1 to RodLength8 | Defines the length of the rods Property type: Numeric Default Value: N/A Validation rule: ≥ 0 Display Options: Decimals: 1 Unit: m
Linked 3D Movement | Link to a 3D movement feature that can be used in evaluations to monitor the movement of the Top point of the inclinometer.

Property structure for type specific observation data

Property, Property Collection | Description
Zero reading |
Measurement1 to Measurement8 | Property type: Numeric Default Value: null Display Options: Decimals: 3 Unit: mm
Delta1 to Delta8 | Property type: Numeric Default Value: null Display Options: Decimals: 3 Unit: mm

Table 2: Properties and collections of the type specific observation data property structure


Inclinometer

Last edited: 10/5/2017 11:51:20 AM

Represents subsurface movements and deformations in different depths.

Characteristic | Note
Name | Inclinometer
Path | \Geotechnics
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed Geometry types | Point, line
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
Azimuth AZIMUTH | Used in conjunction with Dip (see below) to describe the spatial orientation of the borehole in which the inclinometer is installed. 0 means North direction in the underlying coordinate system. Property type: Numeric Default Value: 0 Validation rule: ≥ 0 and <360 Display Options: Decimals: 0 Unit: ° (Degree)
Dip | Used in conjunction with Azimuth (see above) to describe the spatial orientation of the bore hole in which the inclinometer is installed. 0 is horizontal, 90° is perpendicular up, -90 is perpendicular down Default Value: 90 Validation rule: ≥ -90 and ≤ 90 Display Options: Decimals: 0 Unit: ° (Degree)
A0 Direction | Defines the direction of the A0 notch Property type: Numeric Default Value: 0 Validation rule: ≥ 0 and <360 Display Options: Decimals: 0 Unit: ° (Degree)
Evaluation Direction | Defines a direction that can be used to evaluate the inclinometer observations in a direction different than A or B Property type: Numeric Default Value: 0 Validation rule: ≥ 0 and <360 Display Options: Decimals: 0 Unit: ° (Degree)
Fix point on top | Defines where the (expected) fix point of the inclinometer is. Default Value: false
Linked 3D Movement | Link to a 3D movement feature that can be used in evaluations to monitor the movement of the Top point of the inclinometer.

Property structure for type specific observation data

 | Description
Zero reading | Property type: Boolean

Table 2: Properties on level 0

Measurements

Collection of measurements for each depth in A and B direction

Property, Property Collection | Description
Measurements.Depth | Property type: Numeric Default Value: null Validation rule: ≥0 Display Options: Decimals: 3 Unit: m
Measurements.A | Deviation in A direction Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5 Unit: mm
Measurements.B | Deviation in B direction Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5 Unit: mm
Measurements.Zero reading | Marks the measurement in this depth as zero reading Property type: Boolean Default Value: false
Measurements.Erroneous | Marks the measurement in this depth as erroneous Property type: Boolean Default Value: false

Table 3: Properties for elements in the measurements collection


%Text%

Navigation: Appendices > Feature types > Geotechnics >

Q-System

Last edited: 10/5/2017 11:51:32 AM

This feature type is used for geomechanical classifaction for rocks according to the Q-System (RMR) system develped byBarton, Lien, and Lunde. It includes properties for each of the parameters and calculated properties for the Q-Bas and Q-Value.

Characteristic | Note
Name | Q-System
Path | \Geotechnics
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on observation (SSO)
Allowed spatial systems | All
Allowed Geometry types | Point, line, polygon
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection | Description
RQD (Rock Quality Designation) RQD | Designation of Rock Quality Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 100 Display Options: Decimals: 0
Jn Bas JnBasic | Joint set number Property type: Numeric Default Value: none Validation rule: ≥ 3 and ≤ 20 Display Options: Decimals: 1 Hide trailing zeros: true
Jn Correction JnCorrection | Joint Set Correction Property type: Numeric Default Value: none Validation rule: ≥ 1 and ≤ 3 Display Options: Decimals: 0 Hide trailing zeros: true
Jn Jn | Joint set number (corrected) Calculated property. Calculated with formula: Jn = JnBasic*JnCorrection Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 6 Display Options: Decimals: 0 Hide trailing zeros: true
Jr Jr | Joint Roughness number Property type: Numeric Default Value: none Validation rule: ≥ 0.5 and ≤ 5 Display Options: Decimals: 1 Hide trailing zeros: true
Ja Ja | Joint Alteration Number Property type: Numeric Default Value: none Validation rule: ≥ 0.05 and ≤ 20 Display Options: Decimals: 0 Hide trailing zeros: true
Jw Jw | Joint Water Reduction Factor Property type: Numeric Default Value: none Validation rule: ≥ 0.05 and ≤ 1 Display Options: Decimals: 0 Hide trailing zeros: false
SRF SRF | Stress reduction factor Property type: Numeric Default Value: none Validation rule: ≥ 0.5 and ≤ 200 Display Options: Decimals: 0 Hide trailing zeros: true
QBas QBas | Property type: Numeric Calculated property. Calculated with formula: QBase = Max(RQD,10)/JnBas * Jr/Ja Default Value: none Validation rule: ≥ 0 and ≤ 15 Display Options: Decimals: 0
Q Q | Property type: Numeric Calculated property. Calculated with formula: Q = (Max(RQD,10) / (JBas* JCorr)) * (Jr/Ja) * (Jw/SRF) Default Value: none

Table 2: Properties and collections of the type specific observation data property structure


Rock Mass Rating

Last edited: 10/5/2017 11:51:20 AM

This feature type is used for geomechanical classifaction for rocks according to the Rock Mass Rating (RMR) system develped by Z. T. Bieniawski. It includes properties for each of the six parameters that are used to classify a rock mass with the RMR system as well as the resulting RMR value and the resulting Rock quality class.

Characteristic | Note
Name | Rock Mass Rating
Path | \Geotechnics
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on observation (SSO)
Allowed spatial systems | All
Allowed Geometry types | Point, line, polygon
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection | Description
Strength Rating STRENGTH | Rating of the strength of Intact Rock Material Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 15 Display Options: Decimals: 0
RQD Rating RQD | Rating of the Drill Core Quality Property type: Numeric Default Value: none Validation rule: ≥ 3 and ≤ 20 Display Options: Decimals: 0
Discontinuity spacing rating SPACING | Rating of the Discontinuity spacing Property type: Numeric Default Value: none Validation rule: ≥ 5 and ≤ 20 Display Options: Decimals: 0
Discontinuity Length Rating LENGTH | Persistence Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 6 Display Options: Decimals: 0
Discontinuity Separation rating SEPARATION | Aperture Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 6 Display Options: Decimals: 0
Discontinuity Roughness rating ROUGHNESS | Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 6 Display Options: Decimals: 0
Discontinuity Infilling Rating INFILLING | Gouge Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 6 Display Options: Decimals: 0
Discontinuity Weathering rating WEATHERING | Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 6 Display Options: Decimals: 0
Ground water rating GROUNDWATER | Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 15 Display Options: Decimals: 0
Rating adjustment ADJUSTMENT | Property type: Numeric Default Value: none Validation rule: ≥ -60 and ≤ 0 Display Options: Decimals: 0
RMR value RMR | Rock mass rating value Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 100 Display Options: Decimals: 0
Rock Quality Class CLASS | RMR Rock Quality Property type: Classification

Table 2: Properties and collections of the type specific observation data property structure


Hydrology

Last edited: 10/5/2017 11:51:20 AM

Feature types in this path represent phenomena that are usually observed in course of hydro(goe)logical monitoring projects.


Evidence preservation

Last edited: 10/5/2017 11:51:46 AM


In situ characteristic lantic water

Last edited: 3/16/2018 6:55:04 AM

Represents characteristics of lantic water (like lakes, wells, etc) that can usually be observed in situ.

Characteristic | Note
Name | In situ characteristic lantic water
Path | \Hydrology\Water Evidence Securing
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
FEATURESTATUS Status Status | Status of the ground water level. Property type: Classification of type Ground water level status
InformationSource Information source Informationskällor | Describes the source of the information recorded for this ground water level. Property Type: Text Default Value: none Display Options: single-line
NOTES Notes Anmärkning | General notes Property Type: Text Default Value: none Display Options: Multi-line
Locationdescription Location description Lägesbeskrivning | Description of the location of the drill hole Property Type: Text Default Value: none Display Options: Multi-line
PositioningType Positioning type Koordinatkvalitet | Property type: Classification of type Positioning type.
PositioningAccuracyHorizontal Positioning accuracy horiz. Kvalitetsangivelse (plan) | Property type: Classification of type Positioning accuracy
PositioningAccuracyHeight Positioning accuracy height. Kvalitetsangivelse höjd | Property type: Classification of type Positioning accuracy
REFERENCELEVEL Reference level Referensnivå | Elevation of the point from which measurements are done. Value is expressed in the underlying vertical coordinate system. Property type: Numeric Default Value: null Validation rule: ≥ -420 and ≤ 8848 Display Options: ·Integer places: 3 ·Decimal places: 2 ·Display unit: m

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Water level WATER_LEVEL | Numeric value expressing the elevation of the water. Expressed in the unit of the underlying vertical coordinate system. Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 3
Air temperature AIR_TEMPERATURE | Thermodynamic temperature of water Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -91.5 and Value ≤ 70.7 Display Options: Decimals: 2
Water temperature WATER_TEMPERATURE | Property Type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -50 and Value ≤ 200 Display Options: Decimals: 2
PH Value PH | Property type: Numeric Default Value: null Validation rule: Value ≥ 0 Value ≤ 14 Display Options: Decimals: 2
Redox REDOX | Property Type: Quantity of type Electrical potential difference Default Value: null Default Unit: mV Validation rule: Value ≥ -2000 and Value ≤ 2000 Display Options: Decimals: 2
O2 O2 | Property Type: Quantity of type Mass / Volume Default Value: null Default Unit: mg / l Validation rule: none Display Options: Decimals: 2
Conductivity CONDUCTIVITY | Property Type: Quantity of type electrical conductivity Default Value: null Default Unit: µS/m Validation rule: none Display Options: Decimals: 2
TDS TDS | Total dissolved solids Property Type: Quantity of type Mass / Volume Default Value: null Default Unit: mg / l Validation rule: none Display Options: Decimals: 2

Table 3: Properties and collections of the type specific observation data property structure


In situ characteristic lotic water

Last edited: 3/16/2018 6:55:40 AM

Represents characteristics of lotic water (springs, rivers, etc.) that can usually be observed in situ.

Characteristic | Note
Name | In situ characteristic logic water
Path | \Hydrology\Water Evidence Securing
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
FEATURESTATUS Status Status | Status of the ground water level. Property type: Classification of type Ground water level status
InformationSource Information source Informationskällor | Describes the source of the information recorded for this ground water level. Property Type: Text Default Value: none Display Options: single-line
NOTES Notes Anmärkning | General notes Property Type: Text Default Value: none Display Options: Multi-line
Locationdescription Location description Lägesbeskrivning | Description of the location of the drill hole Property Type: Text Default Value: none Display Options: Multi-line
PositioningType Positioning type Koordinatkvalitet | Property type: Classification of type Positioning type.
PositioningAccuracyHorizontal Positioning accuracy horiz. Kvalitetsangivelse (plan) | Property type: Classification of type Positioning accuracy
PositioningAccuracyHeight Positioning accuracy height. Kvalitetsangivelse höjd | Property type: Classification of type Positioning accuracy
REFERENCELEVEL Reference level Referensnivå | Elevation of the point from which measurements are done. Value is expressed in the underlying vertical coordinate system. Property type: Numeric Default Value: null Validation rule: ≥ -420 and ≤ 8848 Display Options: ·Integer places: 3 ·Decimal places: 2 ·Display unit: m

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Water flow rate WATER_FLOWRATE | Amount of water delivered or flowing Property type: Quantity of type Volume / Time Default Value: null Default Unit: l / s Validation rule: Value ≥ 0 Display Options: Decimals: 2
Air temperature AIR_TEMPERATURE | Thermodynamic temperature of water Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -91.5 and Value ≤ 70.7 Display Options: Decimals: 2
Water temperature WATER_TEMPERATURE | Property Type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -50 and Value ≤ 200 Display Options: Decimals: 2
PH Value PH | Property type: Numeric Default Value: null Validation rule: Value ≥ 0 Value ≤ 14 Display Options: Decimals: 2
Redox REDOX | Property Type: Quantity of type Electrical potential difference Default Value: null Default Unit: mV Validation rule: Value ≥ -2000 and Value ≤ 2000 Display Options: Decimals: 2
O2 O2 | Property Type: Quantity of type Mass / Volume Default Value: null Default Unit: mg / l Validation rule: none Display Options: Decimals: 2
Conductivity CONDUCTIVITY | Property Type: Quantity of type electrical conductivity Default Value: null Default Unit: µS/m Validation rule: none Display Options: Decimals: 2
TDS TDS | Total dissolved solids Property Type: Quantity of type Mass / Volume Default Value: null Default Unit: mg / l Validation rule: none Display Options: Decimals: 2

Table 3: Properties and collections of the type specific observation data property structure


Water resource

Last edited: 10/5/2017 11:51:46 AM

Represents a water resource as monitored in water evidence securing projects. Water resources can be: springs, wells, ground water probes, lantic and lotic waters.

Characteristic | Note
Name | Water resource
Path | \Hydrology\Water Evidence Securing
Feature type icon |
Feature type class | Container
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | In situ characteristic lantic water In situ characteristic lotic water

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Figure 1: The structure of the type specific data for the property structure.

Property, Property Collection
Identifier

Description

Maisterial Identity

Behördliche Identität

MAGISTERIAL_ID

ID under which the water resource is registered at the responsible ater authority.

Identität unter der die Wasserressreource bei der zuständigen Behöder registriert ist.

Property type: String

Default Value:

Validation rule: Length <= 200

Display Options:

ID in Project

Identität in Projekt

ID_IN_PROJECT

ID under which the water resource is known in the evidence securing project.

ID unter der die Wasserressource im aktuellen Beweissicherungsprojekt geführt wird.

Property type: String

Default Value:

Validation rule: Length <= 200

Display Options:

Local name

Lokale Bezeichnung

LOCAL_NAME

Name under which the water resource is known locally.

Name unter dem die Wasserressouce lokal bekannt ist.

Property type: String

Default Value:

Validation rule: Length <= 200

Display Options:

Number of outlets

Anzahl der Quelläste

NUMBER_OF_OUTLETS

Property that is relevant for springs only. Defines how many outlets the spring has.

Nur relevant für Wasserressourcen vom Typ Quelle. Speizifiziert die Anzahl der Quelläste.

Property type: Numeric

Default Value:

Validation rule: >=1

Display Options: Decimals: 0

Recording date

Aufnahmedatum

RECORDING_DATE

Date when the information about the water resource was collected.

Datum an dem die Daten zu dieser Wasserressource erhoben wurden.

Property type: String

Default Value:

Validation rule: Length <= 20

Display Options:

Land register authority

Grundbuch Behörde

LAND_REGISTER_AUTHORITY

Authority that is responsible for registration of the lot on which the water resource is located.

Behörder dem das Grundstück auf dem die Wasserressource liegt registriert ist. In Österreich Katastralgemeinde

Property type: Classification of type: Land Register Authority

Lot No.

Grunstück Nr.

LOT_NO

Number under which the lot is registred at the responsible Authority.

Nummer oder Kennzeichnung des Grundstücks auf dem sich die Wasserressource befindet.

Property type: String

Default Value:

Validation rule: Length ≤ 200

Display Options:

Meausremnt point height

Messpunkthöhe

MEASUREMENTPOINT_HEIGHT

Height at which the measurement tool is set for measuring height (or depth) of the water level.

Höhe an der das Messinstrument zur Messung des Wasserstandes angesetzt wird.

Property type: Numeric

Default Value:

Validation rule: ≥-200, ≤ 9000

Display Options: Decimals: 3

Measurability

Beweissicherbarkeit

MEASURABILITY

Defines to what extent the water resource can be measured or monitored for securing evidence.

Definiert die Messbarkeit der Wasserresource im Sinne der Wasserwirtschaftlichen Beweissicherung

Property type: Classification of type: Waterresource Measurability

Evidence preservation since

Beweissicherung seit

EVIDENCE_PRESERVATION_SINCE

States since when evidence preservation was carried out for this water resource.

Definiert seit wann die Wasserressource einer Beweissicherung unterzogen ist

Property type: String

Default Value:

Validation rule: Length <= 20

Display Options:

Evidence preservation interval

Beweissicherungsintervall

EVIDENCE_PRESERVATION_INTERVAL

Defines the time interval in which the water resource is monitored in order to preserve evidence of its characteristics.

Property type: String

Default Value:

Validation rule: Length <= 100

Display Options:

Evidence preservation plan

Beweissicherungsprogramm

EVIDENCE_PRESERVATION_PLAN

Actions to take in order to preserve evidence for this water resource.

Zur Beweissicherung auszuführende Beweissicherungsprogramme, bzw. Tätikeiten.

Property type: String

Default Value:

Validation rule:

Display Options: Multiline: true

Reaosn for evidence preservation plan

Begründung der Beweissicherung

REASON_FOR_EVIDENCE_PRESERVATION

Describes the reasons for the evidence preservation plan and the preservation interva.

Begründung für die auszuführenden Beweissicherungsmaßnhamen bzw. auch für das Messintervall.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Utilization category

Nutzungskategorie

UTILIZATION_CATEGORY

Specifies the category of utilization of this water resource.

Definiert wie die Wasserressource verwendet wird. Z.B. Privat oder Öffentlich.

Property type: Classification of type: Water Resource Utilization Category

Utilization purpose

Nutzungszweck

UTILIZATION_PURPOSE

Describes the purpose of the utilization.

Beschreibt wie die Wasserressoruce genützt wird.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Utilization type

Nutzungsart

UTILIZATION_TYPE

Defines how the water of this resource is used

Definiert wie die Wasserressource verwendet wird

Property type: Classification of type: Water Resource Utilization Type

Utilization Intensity

Nutzungsintensität

UTLIZATION_INTENSITY

Defines the intensity of utilization of this water resource.

Definiert wie oft die Wasserressource genutzt wird

Property type: Classification of type: Water Resource Utilization Intensity

Water facility description

Beschreibung der Wasserentnahmeanlage

WATER_FACILITY_DESCRIPTION

Describes the facility used to withdraw water form the water resource.

Beschreibung der wasserentnahme und ggf. Rückführungsanlage aus technische Sicht. z.B. Beschreibung der Quellfassungsanlage, des Entnahmebrunnens oder der Wärmepumpe.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Water rights register No.

Wasserbuch PZ

WATERRIGHTS_REGISTER_NO

The number under which the water resource is registred with the responsible authority.

Wasserbuch PZ für diese Wasserressource.

Property type: String

Default Value:

Validation rule: Length <= 100

Display Options:

In water protection area

In Wasserschutzgebiet

IN_WATER_PROTECTION_AREA

Defines if the water resource is located in a water protection area.

Definiert ob die Wasserressource in einem Wasserschutzgebiet liegt oder nicht.

Property type: Boolean

Default Value:

Utilization limitation

Nutzungsbeschränkung

UTILIZATION_LIMITATION

Specifies if the utilization of the water is limited by the water legislation or not. If limited the utilization limit property can be used to specify the limit.

Definiert ob bei der Nutzung der Wasserressource eine Limitierung besteht.

Property type: Boolean

Default Value: null

Utilizationlimit

Nutzungslimit

UTILIZATION_LIMIT

Defines the extent to which the water resource may be used.

Definiert den tatsächlichen Wert der Limitierung der Wassernutzung.

Proeprty type: Quanity of type volumentric flow rate

Default value:

Validation rule: >= 0

Display Options: Decimals: 1

Beneficiary

Berechtigter

BENEFICIARY

Party that is authorized to use water from this water resource.

Die zur Nutzung der Wasserressource berechtigte Person oder Organisation.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

User

Nutzer

USER

Party that is effectively using the water from this water resource.

Der effektive Nutzer der Wasserressource.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Directions

Anfahrtsbeschreibung

DIRECTIONS

Describes how to get to the water ressource

Hinweise zur Anfahrt bzw. zum Erreichen der Wasserressource.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Accessasbility

Erreichbarkeit

ACCESSABILITY

Describes how one can get to this water ressource, e.g. acces by car.

Beschreibt wie die Wasserressource erreicht werden kann. z.B. Zufahrt mit PKW.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Needed Tools

Erforderliche Werkzeuge

NEEDED_TOOLS

Lists the tools (Keys etc) that are necessary to get to the water resource and / or access the water resource.

Beschreibt die Werkzeuge (z.B. Schlüssel) die notwendig sind um die Wasserressource zu erreichen bzw. um Zugang zur Wasserressource oder zu den Messstellen zu erhalten.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Other Information for monitoring

Weitere Information

OTHER_MONITORING_INFORMATION

Any other notes that might be important for the persons monitoring the water resource.

Weitere Notizen die für das Monitoring der Wasserressource wichtig sind.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Spring type

Quelltype

SPRING_TYPE

Classifies the spring according to the geological situation

Klassifiziert eine Quelle aus geologischer Sicht

Property type: Classification of type Springtype

Hydrogeologic notes

Hydrogeologische Anmerkungen

HYDROGEOLOGIC_NOTES

Description of the hydro-geological environment

Beschreibung der hydro geologischen Umgebun. Z.b. Gesteinstyp, Stratigraphie, Gefüge, Anmerkungen.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Notes on Catchment area

Einzugsgebiet

CATCHMENT_AREA

Describes the catchment area of the water resource. E.g. Catchment area in m², hazards etc.

Beschreibung des Einzugsgebietes. Z.b. Fläche des Einzungsgebietes, Verweildauer, Gefährdungen

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Effectclass

Auswirkungsklasse

EFFECTCLASS

Classifies the possibility that the project for which the monitoring is done has a negative effect on the water of this resource.

Klassifiziert die Wahrscheinlichkeit, dass das gegenständliche Projekt negative Auswirkungen auf das Wasser dieser Ressource hat.

Property type: Classification of type Effectclass

Effect description

Auswirkungsbeschreibung

EFFECT_DESCRIPTION

Describes the possible effects that the project for whicht he monitoring is done has

Beschreibt die möglichen Auswirkungen eines bestimmten Projektes auf die Wasserressoruce.

Property type: String

Default Value:

Validation rule:

Display Options: Multi-line text: yes

Recorded by

Aufgenommen von

RECORDED_BY

Recorded by

Aufgenommen von

Property type: String

Default Value:

Validation rule: max 200

Display Options:

Reference water resources

This collection allows linking other features of the same feature type as reference water resources. Especially useful if a water resource cannot be monitored directly.

Property, Property Collection WATER_RESOURCES | Description
Reference water resource Referenz-Wasserressource REFERENCE_WATERRESOURCE | Links a water resource that is a reference for this water resource. Verbindet eine Wasserressource die als Referenz für diese Wasserressource herangezogen werden kann.

Property structure for type specific observation data

This feature type does not define a property structure for type specific observation data.


%Text%

Navigation: Appendices > Feature types > Hydrology >

Ground water level

Last edited: 10/5/2017 11:51:20 AM

Represents the level (=elevation) of ground water monitored in a drill hole.

Characteristic | Note
Version | 4
Name | Ground water level
Path | \Hydrology
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | Point
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
BEARING Bearing Rörlutningsriktning | Used in conjunction with Dip (see below) to describe the spatial orientation of the borehole. 0 means North direction in the underlying coordinate system. Property type: Numeric Default Value: 0 Validation rule: ≥ 0 and <360 Display Options: Decimals: 0 Display unit: ° (Degree)
Dip Dip Gradning | Used in conjunction with Azimuth (see above) to describe the spatial orientation of the bore hole. Property type: Numeric 0° is horizontal 90° is perpendicular down -90° is perpendicular up Default Value: 90 Validation rule: ≥ -90 and ≤ 90 Display Options: Decimals: 0 Unit: ° (Degree)
AquiferType Aquifer type Magasin | Defines the ground water magazine this ground water level refers to. Property type: Classification of type Aquifer type
MAGAZINE Magazine Grundvattenmagasin | Defines the type of the aquifer whose water level is observer. Property type: Classification of type Ground water magazine
DRILLHOLETYPE Drillhole type Rörtyp | Defines the type of drilling in which the ground water level is measured Property type: Classification of type Drilling type
ReferenceElevation Reference elevation Referensnivå | Elevation of the point from which depth measurements are done (in many cases top edge of the pipe). Value is expressed in the underlying vertical coordinate system. Property type: Numeric Default Value: null Validation rule: ≥ -420 and ≤ 8848 Display Options: ·Integer places: 3 ·Decimal places: 2 ·Display unit: m
Filterlength Filter length Längd på filter | Length of the filter within the borehole Property type: Numeric Default Value: null Validation rule: ≥ 0 and ≤ 1000 Display Options: ·Integer places: 3 ·Decimal places: 2 ·Display unit: m
ELEVATIONOFEND Final Depth Spetsnivå | Elevation of final depth of the drilling. Value is expressed in the underlying vertical coordinate system. Property type: Numeric Default Value: null Validation rule: ≥ -420 and ≤ 8848 Display Options: ·Integer places: 3 ·Decimal places: 2 ·Display unit: m
MAXLEVELLINGDEPTH Max. levelling depth Max Pejlbart Djup | Property type: Numeric Default Value: null Validation rule: ≥ 0 and ≤ 1000: Display Options: ·Integer places: 3 ·Decimal places: 2 ·Display unit: m
INSTALLATIONDEPTH Installation depth Installationsdjup | Property type: Numeric Default Value: null Validation rule: ≥ 0 and ≤ 1000: Display Options: ·Integer places: 3 ·Decimal places: 2 ·Display unit: m
PUMPDEPTH Pump depth Pumpdjup | Property type: Numeric Default Value: null Validation rule: ≥ 0 and ≤ 1000: Display Options: ·Integer places: 3 ·Decimal places: 2 ·Display unit: m
FeedpipeLength Length of feedpipe Längd av Foderrör | Property type: Numeric Default Value: null Validation rule: ≥ 0 and ≤ 1000: Display Options: ·Integer places: 3 ·Decimal places: 2 ·Display unit: m
Filled Filled Igengjuten | Property type: Boolean filled or not
FEATURESTATUS Status Status | Status of the ground water level. Property type: Classification of type Ground water level status
InformationSource Information source Informationskällor | Describes the source of the information recorded for this ground water level. Property Type: Text Default Value: none Display Options: single-line
NOTES Notes Anmärkning | General notes Property Type: Text Default Value: none Display Options: Multi-line
Locationdescription Location description Lägesbeskrivning | Description of the location of the drill hole Property Type: Text Default Value: none Display Options: Multi-line
Installationdate Installationdate Anläggnings- / Installationsdatum | Property type: Date time
INVENTORYDATE Inventory date Inventeringsdatum | Property type: Date time
Filtertype Filtertype Filtertyp | Type of filter used in this drillhole. Property type: Classification of type Filter type
Pipedimension Pipedimension Rördimension | Property type: Classification of type Pipe dimension
Tiptype Tip type Spetstyp | Property type: Classification of type Tip type
Coordinatesource Positioning type Koordinatkvalitet | Property type: Classification of type Positioning type.
POSITIONINGACCURACYHORIZONTAL Positioning accuracy horiz. Kvalitetsangivelse (plan) | Property type: Classification of type Positioning accuracy
POSITIONINGACCURACYHEIGHT Positioning accuracy height. Kvalitetsangivelse höjd | Property type: Classification of type Positioning accuracy

Table 2: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

Property, Property Collection Identifier | Description
WATERLEVEL Water level Level | Absolute elevation of ground water at the time of measurement. Elevation is expressed in the underlying vertical coordinate system. Property type: Numeric Default Value: null Display Unit: m Validation rule: ≥ -420 and ≤ 8848 Display Options: ·Integer places: 3 ·Decimal places: 2 ·Display unit: m
POREPRESSURE Pore pressure portryck | Property type: Numeric Default Value: null Display Options: ·Integer places: 4 ·Decimal places: 2 ·Display unit: kPa
STANDARDCOMMENT Standard comment Standardkommentar | This classification property can be used to tag ground water readings. Property type: Classification of type Standard comment.

Table 3: Properties and collections of the type specific observation data property structure


In situ water characteristic

Last edited: 3/16/2018 6:56:02 AM

Represents characteristics of water that can usually be observed in situ.

Characteristic | Note
Name | In situ water characteristic
Path | \Hydrology
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
FEATURESTATUS Status Status | Status of the ground water level. Property type: Classification of type Ground water level status
InformationSource Information source Informationskällor | Describes the source of the information recorded for this ground water level. Property Type: Text Default Value: none Display Options: single-line
NOTES Notes Anmärkning | General notes Property Type: Text Default Value: none Display Options: Multi-line
Locationdescription Location description Lägesbeskrivning | Description of the location of the drill hole Property Type: Text Default Value: none Display Options: Multi-line
PositioningType Positioning type Koordinatkvalitet | Property type: Classification of type Positioning type.
PositioningAccuracyHorizontal Positioning accuracy horiz. Kvalitetsangivelse (plan) | Property type: Classification of type Positioning accuracy
PositioningAccuracyHeight Positioning accuracy height. Kvalitetsangivelse höjd | Property type: Classification of type Positioning accuracy

Table 2: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Air temperature AIR_TEMPERATURE | Thermodynamic temperature of water Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -91.5 and Value ≤ 70.7 Display Options: Decimals: 2
Water temperature WATER_TEMPERATURE | Property Type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -50 and Value ≤ 200 Display Options: Decimals: 2
PH Value PH | Property type: Numeric Default Value: null Validation rule: Value ≥ 0 Value ≤ 14 Display Options: Decimals: 2
Redox REDOX | Property Type: Quantity of type Electrical potential difference Default Value: null Default Unit: mV Validation rule: Value ≥ -2000 and Value ≤ 2000 Display Options: Decimals: 2
O2 O2 | Property Type: Quantity of type Mass / Volume Default Value: null Default Unit: mg / l Validation rule: none Display Options: Decimals: 2
Conductivity CONDUCTIVITY | Property Type: Quantity of type electrical conductivity Default Value: null Default Unit: µS/m Validation rule: none Display Options: Decimals: 2
TDS TDS | Total dissolved solids Property Type: Quantity of type Mass / Volume Default Value: null Default Unit: mg / l Validation rule: none Display Options: Decimals: 2
Remarks REMARKS | General remarks Property Type: Text Default Value: none Display Options: Multi line

Table 3: Properties and collections of the type specific observation data property structure


%Text%

Navigation: Appendices > Feature types > Hydrology >

Infiltration

Last edited: 10/5/2017 11:51:20 AM

This feature type describes the infiltration of water in a borehole

Characteristic | Note
Version | 1
Name | Infiltration
Path | \Hydrology
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | Point
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
BEARING Bearing Rörlutningsriktning | Used in conjunction with Dip (see below) to describe the spatial orientation of the borehole. 0 means North direction in the underlying coordinate system. Property type: Numeric Default Value: 0 Validation rule: ≥ 0 and <360 Display Options: ·Decimals: 0 ·Display unit: ° (Degree)
Dip Dip Gradning | Used in conjunction with Azimuth (see above) to describe the spatial orientation of the bore hole. Property type: Numeric 0 is horizontal, 90° is perpendicular down, -90 is perpendicular up Default Value: 90 Validation rule: ≥ -90 and ≤ 90 Display Options: ·Decimals: 0 ·Unit: ° (Degree)
FinalDepth Final Depth Spetsnivå | Elevation of final depth of the drilling Value is expressed in the underlying vertical coordinate system. Property type: Numeric Default Value: null Display Options: ·Decimals: 3 ·Display unit: m
FILTERLENGTH Filter length Filterlängd | Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Display unit: m
CAPACITY Capacity Kapacitet | Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Display unit: l/min
AquiferType Aquifer type Grundvattenmagasin | Defines the type of the aquifer whose water level is observer. Property type: Classification of type Aquifer type
FeatureStatus Status Status | Status of the ground water level. Property type: Classification of type Feature status
InstallationDepth Installation depth Installationsdjup | Depth where sensors are installed Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Display unit: m
MAXLEVELLINGDEPTH Max. leveling depth Max Pejlbart Djup | Property type: Numeric Default Value: null Validation rule: Display Options: ·Decimals: 2 ·Display unit: m
Filled Filled Igengjuten | Property type: Boolean
Pipedimension Pipedimension Rördimension | Property type: Classification of type Pipe dimension
Coordinatesource Positioning type Koordinatkvalitet | Property type: Classification of type Positioning type.
Installationdate Installationdate Anläggnings- / Installationsdatum | Property type: Date time
ESTIMATEDInstallationDATE Estimated installation date Uppskattat installationsdatum | Property type: Text Default Value: none Display Options: Single-line
INVENTORYDATE Inventory date Inventeringsdatum | Property type: Date time
Generalnotes Notes Anmärkning | General notes Property Type: Text Default Value: none Display Options: Multi-line
Locationdescription Location description Lägesbeskrivning | Description of the location of the drill hole Property Type: Text Default Value: none Display Options: Multi-line
POSITIONINGACCURACYHORIZONTAL Positioning accuracy horiz. Kvalitetsangivelse (plan) | Property type: Classification of type Positioning accuracy
POSITIONINGACCURACYHEIGHT Positioning accuracy height. Kvalitetsangivelse höjd | Property type: Classification of type Positioning accuracy
INFILTRATIONTYPE Infitlration type Infiltrationstyp | Property type: Classification of type Infiltration type
DRILLHOLETYPE Drillhole type Rörtyp | Defines the type of drilling in which the ground water level is measured Property type: Classification of type Drilling type

Table 2: Properties of the extended feature data of this feature type

Property structure for type specific observation data

Property | Description
CurrentFLOW Current flow Momentant flöde | Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Display unit: l/min
MEANFLOW Mean Flow Medel flöde | Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Display unit: l/min
CumulativeVOLUME Cumulative volume Kumulativ volym | Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Default unit m³

Table 3: Properties of the extended observation data of this feature type


%Text%

Navigation: Appendices > Feature types > Hydrology >

Pore water pressure

Last edited: 10/5/2017 11:51:30 AM

This feature type represents pore water pressure, i.e. the pressure of groundwater held within a soil or rock, in gaps between particles (pores).

Characteristic | Note
Name | Pore Water Pressure
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Pressure PRESSURE | Property type: Quantity of type Pressure Default Value: null Default Unit: Pa Validation rule: none Display Options: Decimals: 5
Temperature TEMPERATURE | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -5 and ≤ 100 Display Options: Decimals: 2

Table 2: Properties and collections of the type specific observation data property structure


Spring

Last edited: 10/5/2017 11:51:20 AM

This feature type represents a spring. It is platform for numerous other spring and water related feature types.

Characteristic | Note
Name | Spring
Path | \Hydrology
Feature type icon |
Feature type class | Platform
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed Geometry types | All
Allowed contained feature types | In situ water characteristic (any number) Volumetric flow rate (any number)

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection Identifier | Description
Identifier Identifier | A (usually unique) string usually issued by some organization Property type: Text Default value: none Validation rule: none Display settings: single line
Location Location | Description of the location of the spring Property type: Text Default value: none Validation rule: none Display settings: multi line

Table 2: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

This feature type has no type specific observation data.


%Text%

Navigation: Appendices > Feature types > Hydrology >

Water afflux

Last edited: 10/5/2017 11:51:44 AM

This feature type represents the total water afflux for a section in a tunnel or in a specific area.

Characteristic | Note
Name | Water afflux
Path | \Hydrology
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Identifying name Property | Description
BASINTYPE Basin type Pumpgropstyp | Property type: Classification of type Basin type.
SITETYPE Sitetype Anläggningstyp | Property type: Classification of type Site type
ARea Area Delsträcka | Description of the area for which the water is summed at this feature. Property Type: Text Default Value: none Display Options: Multi-line
SEALINGTYPE Sealing type Tätningstyp | Property type: Classification of type Basin Sealing type
Measurementtype Type of mesurement Mätpunkstyp | Property type: Classification of type Measurement type
Length Length Längd (m) | Length of the section in the tunnel that is summed in this feature. Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: Decimals: 1 Display unit: m
Width Width Bredd (m) | Width of the section in the tunnel that is summed in this feature. Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: Decimals: 1 Display unit: m
Installationdate Installationdate Anläggnings- / Installationsdatum | Date and time when this feature was installed. Property type: Date time
INVENTORYDATE Inventory date Inventeringsdatum | Date and time when this feature was last inspected. Property type: Date time
Generalnotes Notes Anmärkning | General notes Property Type: Text Default Value: none Display Options: Multi-line
Locationdescription Location description Lägesbeskrivning | Description of the location of the drill hole Property Type: Text Default Value: none Display Options: Multi-line
Coordinatesource Positioning type Koordinatkvalitet | Property type: Classification of type Positioning type.
POSITIONINGACCURACYHORIZONTAL Positioning accuracy horiz. Kvalitetsangivelse (plan) | Property type: Classification of type Positioning accuracy
POSITIONINGACCURACYHEIGHT Positioning accuracy height. Kvalitetsangivelse höjd | Property type: Classification of type Positioning accuracy

Table 2: Properties of the extended feature data of this feature type

Property structure for type specific observation data

Identifying name Property | Description
ExpectedFlow Expected flow Förväntat flöde | Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Display unit: l/min · This is used as a helper and is just manually input
XX Leakage subsection Inläckage delsträcka | Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Display unit: l/min This is the expected flow (budget) in volume/time/tunnelmeter Was calculated outside of TMO but would be nice to have in Redbex (ofcourse) Unit l/min/m?
CurrentFLOW Current flow Momentant flöde | Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Display unit: l/min
MEANFLOW Mean Flow Medel flöde | Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Display unit: l/min
CumulativeVOLUME Cumulative volume ??? | Property type: Numeric Default Value: null Validation rule: ≥ 0 Display Options: ·Decimals: 2 ·Default unit m³

Table 3: Properties of the extended observation data of this feature type


Water analysis

Last edited: 10/5/2017 11:51:20 AM

This feature type represents the result of a laboratory analysis. The structure of this feature type is mainly influenced by the Interlab data format.

Characteristic | Note
Name | Water analysis
Path | \Hydrology
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A
Single observation | No

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
FEATURESTATUS Status Status | Status of the ground water level. Property type: Classification of type Ground water level status
InformationSource Information source Informationskällor | Describes the source of the information recorded for this ground water level. Property Type: Text Default Value: none Display Options: single-line
NOTES Notes Anmärkning | General notes Property Type: Text Default Value: none Display Options: Multi-line

Table 2: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

Property, Property Collection | Description
Analysis class ANALYSISCLASS Interlab: REGISTERTYP | Can be used to classify different basic types of analyses. Classification of type Laboratory Analysis Class
Analysis reason ANALYSISREASON Interlab: PROVTAGNINGSORSAK | Classification of type Laboratory Analysis Reason
Assessment comment ASSESSMENTCOMMENT Interlab: KOMMENTAR | Comment on the assessment of water quality. Property Type: Text Default Value: none Display Options: none
Chemical assessment CHEMICALASSESSMENT Interlab: KEMISK BEDÖMNING | Classification of type Quality assessment Assessment of the water quality with regard to the analysis of chemical parameters.
Analysis results ANALYSISRESULTS | Collection of analysis results. See table 3 for details.
Client Address CLIENTADDRESS Interlab: ADRESS | Address of the client for whom the analysis was done Property Type: Text Default Value: none Display Options: none
Client City CLIENTCITY Interlab: ORT | City of the client for whom the analysis was done Property Type: Text Default Value: none Display Options: none
Client municipality code CLIENTMINICIPALITYCODE Interlab: KOMMUNKOD | ID or code fo the municipality for which the analysis was done Property Type: Text Default Value: none Display Options: none
Client Name CLIENTNAME Interlab: NAMN | Name of the client for whom the analysis was done. Property Type: Text Default Value: none Display Options: none
Client Zip Code CLIENTZIPCODE Interlab: POSTNR | ZIP code of the client for whom the analysis was done Property Type: Text Default Value: none Display Options: none
Laboratory LABORATORY Interlab: LABORATORIUM | Name of the laboratory that analyzed the sample. Property Type: Text Default Value: none Display Options: none
Microbiological assessment MICROBIOLOGICALASSESSMENT Interlab: MIKROBIOLOGISK BEDÖMNING | Classification of type Quality assessment Assessment of the water quality with regard to the analysis of microbiological parameters.
Overall assessment OVERALLASSESSMENT Interlab: BEDÖMNING | Comments in relation to the assessment Property Type: Text Default Value: none Display Options: none
Probe site ID PROBESITEID Interlab: PROVPLATSID | ID of the location where the samples are taken Property Type: Text Default Value: none Display Options: none
Probe site name PROBESITENAME Interlab: PROVPLATSNAMN | Name of the location where the samples are taken Property Type: Text Default Value: none Display Options: none
Project name PROJECTNAME Interlab: PROJEKT | Name of the project for which the analysis was done Property Type: Text Default Value: none Display Options: none
Sampling specification SAMPLINGSPECIFICATION Interlab: PROVTYPSPECIFIKATION | Property Type: Text Default Value: none Display Options: none
Sampler SAMPLER Interlab: PROVTAGARE | Name of the Person who took the analyzed sample. Property Type: Text Default Value: none Display Options: none
Sampling type SAMPLINGTYPE Interlab: PROVTYP | Classification of type Water analysis sampling type

Table 2: Properties and collections of the type specific observation data property structure on level 0

Property | Description
Accuracy ACCURACY Interlab: MÄTOSÄCKERHET | Specification of the accuracy of the analysis result for this parameter Property Type: Text Default Value: none Display Options: none
Detection limit DETECTIONLIMIT Interlb: DETEKTIONSGRÄNS | Value above which the analyzed Parameter can be detected Property Type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 4 Display unit: empty
Method METHOD Interlab: METHODBEDECKNING | Method used to derive a value for a specific parameter. E.g. name of standard. Property Type: Text Default Value: none Display Options: none
Numeric Value NUMERICVALUE Interlab: MÄTVERDETAL | If the analysis result is a numerical value this value is persisted in this property Property Type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 4 Display unit: empty
Parameter PARAMETER Interlab: PARAMETER | Parameter that was analyzed Classification of type Water analysis parameter
Parameter assessment PARAMETERASSESSMENT Interlab: PARAMETERBEDÖMNING | Assessment of the analysis result for this parameter Property Type: Text Default Value: none Display Options: none
Parameter comment PARAMETERCOMMENT Interlab: KOMMENTAR | Comment on the analysis result for this parameter Property Type: Text Default Value: none Display Options: none
Quantification limit QUANTIFICATIONLIMIT Interlab: RAPPORTERINGSGRÄNS | Value above which the analysis result for a parameter can be quantified Property Type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 4 Display unit: empty
Text value TEXTVALUE Interlab: MÄTVERDETEXT | If the analysis result is a textual value this value is persisted in this property Property Type: Text Default Value: none Display Options: none
Trace TRACE Interlab: Mätvärdespår | Property type: Boolean Default value: null
Unit UNIT Interlav: ENHET | Unit of the numerical value Property Type: Text Default Value: none Display Options: none
Value type VALUETYPE Interlab: MÄTVERDETALAMN | Classification of type LaboratoryAnalysisValueType

Table 3: Properties and collections of the type specific observation data property structure for the AnalysisResults collection


%Text%

Navigation: Appendices > Feature types > Hydrology >

Water flow

Last edited: 10/5/2017 11:51:20 AM

This feature type represents the flow of water, i.e. the amount of water that passes through.

Characteristic | Note
Name | Pressure
Path | \Hydrology
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Current flow CurrentFLOW | Property type: Quantity of type Volumetric flow rate Default Value: null Validation rule: none Display Options: Default unit l / min
Mean Flow MEANFLOW | Property type: Quantity of type Volumetric flow rate Default Value: null Validation rule: none Display Options: Default unit l / min
Cumulative volume CumulativeVOLUME | Property type: Quantity of type Volume Default Value: null Validation rule: none Display Options: Default unit m³

Table 2: Properties and collections of the type specific observation data property structure


Surveying

Last edited: 10/5/2017 11:51:20 AM

Feature types in this path are usually used for surveying. Surveying or land surveying is the profession accurately determining the terrestrial or three-dimensional position of points and the distances and angles between them.


3D Movement

Last edited: 10/5/2017 11:51:18 AM

Represents the movement of a point in three dimensions. The three dimensions are expressed in the underlying projected system.

Characteristic | Note
Name | 3D movement
Path | \Surveying
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | Projected coordinate system
Allowed Geometry types | Point
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection Identifier | Description
Expected Movement direction EXPECTED_MOVEMENT | The expected movement direction in the X, Y plane. Used for processing and presentation. The value is interpreted as compass degree i.e. measured clockwise from Y-direction Property type: Numeric Default Value: 0 Validation rule: ≥ 0 and <360 Display Options: Decimals: 0

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Coordinate X COORDINATE_X | Numeric value of the X coordinate. Expressed in the unit of the underlying projected coordinate system. Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Coordinate Y COORDINATE_Y | Numeric value of the Y coordinate. Expressed in the unit of the underlying projected coordinate system. Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Coordinate Z COORDINATE_Z | Numeric value of the Z coordinate. Expressed in the unit of the underlying vertical coordinate system. Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


3D Movement on Profile

Last edited: 10/5/2017 11:51:02 AM

Represents the movement of a point in three dimensions X, Y, Z. The three dimensions are expressed in the underlying projected and vertical coordinate system. Use this feature type for recording movement of points located on a measurement profile as found in tunneling.

Characteristic | Note
Name | 3D movement on Profile
Path | \Surveying
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | Projected coordinate system
Allowed Geometry types | Point
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Coordinate X COORDINATE_X | Numeric value of the X coordinate. Expressed in the unit of the underlying projected coordinate system. Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Coordinate Y COORDINATE_Y | Numeric value of the Y coordinate. Expressed in the unit of the underlying projected coordinate system. Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Coordinate Z COORDINATE_Z | Numeric value of the Z coordinate. Expressed in the unit of the underlying vertical coordinate system. Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


%Text%_2

Navigation: Appendices > Feature types > Surveying >

Ground water level

Last edited: 4/4/2018 10:33:02 AM

Represents the settlement of a point

Characteristic | Note
Version | 1
Name | Settlement
Path | \Surveying
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | Point
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
Placement Placement Placering | Property type: Classification of type Settlement placement
Placementcomment Placement comment Placering kommentar | Comment on the placement of the settlement point. Property Type: Text Default Value: none Display Options: Multi-line
Fixpoint Fixpoint Fixpunkt | Defines the initial or default fixpoint used for this feature Property type: Classification of type Fixpoint
Coordinatesource Positioning type Koordinatkvalitet | Property type: Classification of type Positioning type.
Installationdate Installationdate Anläggnings- / Installationsdatum | Property type: Date time
INVENTORYDATE Inventory date Inventeringsdatum | Property type: Date time
Generalnotes Notes Anmärkning | General notes Property Type: Text Default Value: none Display Options: Multi-line
Locationdescription Location description Lägesbeskrivning | Description of the location of the drill hole Property Type: Text Default Value: none Display Options: Multi-line
POSITIONINGACCURACYHORIZONTAL Positioning accuracy horiz. Kvalitetsangivelse (plan) | Property type: Classification of type Positioning accuracy
POSITIONINGACCURACYHEIGHT Positioning accuracy height. Kvalitetsangivelse höjd | Property type: Classification of type Positioning accuracy

Table 2: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

Property, Property Collection Identifier | Description
ELEVATION Elevation Höjd | Absolute elevation of ground water at the time of measurement. Elevation is expressed in the underlying vertical coordinate system. Property type: Numeric Default Value: null Display Unit: m Validation rule: ≥ -420 and ≤ 8848 Display Options: Decimals: 3
FIXPOINT Fixpoint Fixpunkt | Describes the fixpoint for this measurement Property type: Classification of type Fixpoint

Table 3: Properties and collections of the type specific observation data property structure


Settlement group

Navigation: Appendices > Feature types > Surveying >

SettlementGroup

Last edited: 4/4/2018 10:32:42 AM

This feature type represents a group of related settlement features.

Characteristic | Note
Name | Settlement Group
Path | \Surveying
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | Projected, Geographic
Allowed geometries | Polygon, Multiplolygon
Allowed contained feature types | Settlement

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Subsurface Measurement Profile

Last edited: 10/5/2017 11:51:20 AM

Represents a cross section at a specific point on an axis where measurement sensors are installed.

Characteristic | Note
Name | Measurement profile
Path | \Surveying
Feature type icon |
Feature type class | Platform
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | Axis reference system
Allowed Geometry types | N/A
Allowed contained feature types | 3D Movement on profile

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


%Text%

Navigation: Appendices > Feature types > Surveying >

Surface Measurement Profile

Last edited: 10/5/2017 11:51:42 AM

Represents a surveying profile on the surface. I.e. a arbitrary line on the surface along which 3D movements are mapped for evaluation.

Characteristic | Note
Name | Surface measurement profile
Path | \Surveying
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | Projected coordinate system
Allowed Geometry types | Line
Allowed contained feature types | 3D Movement

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Tipping

Last edited: 10/5/2017 11:51:02 AM

Represents the relation between two points in a projected coordinate system.

Characteristic | Note
Name | Tipping
Path | \Surveying
Feature type icon |
Feature type class | Regular
Spatial data support | On Feature
Allowed spatial systems | Projected Coordinate System
Allowed geometries | Point, Line
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property structure for type specific observation data

Property, Property Collection | Description
Vertical dip | Property type: numeric Default Value: null Validation rule: >=0 <= 180
Horizontal dip | Property type: numeric Default Value: null Validation rule: >=-90 <= 90
Horizontal dip direction | Property type: numeric Default Value: null Validation rule: >=0 <= 360
Delta X | Property type: numeric Default Value: null Validation rule:
Delta Y | Property type: numeric Default Value: null Validation rule:
Delta Z | Property type: numeric Default Value: null Validation rule:
Distance XY | Property type: numeric Default Value: null Validation rule: >= 0
Distance XYZ | Property type: numeric Default Value: null Validation rule: >= 0
Zero Reading |

Table 1: Properties and collections of the type specific feature data property structure


Tunneling

Last edited: 10/5/2017 11:51:20 AM

Feature types in this sections are especially useful for observing phenomena in the area of tunneling.


Axis position

Last edited: 10/5/2017 11:51:18 AM

Represents a changing position on a tunnel axis, e.g. for advance status.

Characteristic | Note
Name | Axis position
Path | \Tunneling
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on observation
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for extended observation


%Text%

Navigation: Appendices > Feature types > Tunneling >

Blasting journal

Last edited: 11/28/2017 11:14:08 AM

Represents a specific blast.

Characteristic | Note
Name | Blasting journal
Path | \Tunneling
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on observation (SSO)
Allowed spatial systems | Any
Allowed Geometry types | Any
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property, Property Collection Identifier | Description

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Blast number | Blast identifier Property type: Text Default Value: null
Section | Defines where in the tunnel the blast took place Property type: Numeric Default Value: null
Type | Property type: Multiple choice Default Value: "Tunnel", other value "Bench"
Supervisor | Property type: Numeric Default Value: null
Drill hole diameter | Property type: Numeric Default Value: null Display unit: mm
Spacing | Property type: Numeric Default Value: null Display unit: m
Burden | Property type: Numeric Default Value: null Display unit: m
Total number of holes | Property type: Numeric Default Value: null
Hole depth min | Property type: Numeric Default Value: null Display unit: m
Hole depth max | Property type: Numeric Default Value: null Display unit: m
Sub drilling | Property type: Numeric Default Value: null Display unit: m
Hole angles | Property type: Numeric Default Value: null Display unit: Degrees
Drill meter total | Property type: Numeric Default Value: null Display unit: m
Total charge | Property type: Numeric Default Value: null Display unit: kg
Total primer | Property type: Numeric Default Value: null Display unit: kg
Stemming | Property type: Numeric Default Value: null Display unit: m
Maximum Instantaneous Charge | Property type: Numeric Default Value: null Display unit: kg
Type of Explosive | Property type: Text Default Value: null
Initiation system and primer | Property type: Text Default Value: null
Area | Property type: Numeric Default Value: null Display unit: m2
Volume | Property type: Numeric Default Value: null Display unit: m3
Powder factor | Property type: Numeric Default Value: null Display unit: kg/m3
Specific drilling | Property type: Numeric Default Value: null Display unit: m/m3
Notes | Property type: Text Default Value: null Display option: Multi line
Type of cover | Property type: Text Default Value: null

Table 2: Properties and collections of the type specific observation data property structure


%Text%

Navigation: Appendices > Feature types > Tunneling >

Bolting protocol

Last edited: 10/5/2017 11:51:18 AM

This feature type is used to record the bolting procedure during the construction of a tunnel.

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Geological mapping in tunnel 001

Navigation: Appendices > Feature types > Tunneling >

Geological mapping in tunnel

Last edited: 10/5/2017 11:51:18 AM

Represents the geological situation along the tunnel axis.

Characteristic | Note
Name | Geological mapping in tunnel 001
Path | \Tunneling
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on observation
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

The property structure for type specific observation data of this feature type is a rich structure containing multiple collections. Figure 1 shows a graphical representation of this property structure.

Figure 1: The structure of the type specific data for observations.

Property Identifying name | Description
Engineering geological description | General notes on the geology. Property type: String Validation rule: N/A Default Value: N/A
Geologist | Person who conducted (and is respoinsible for) the documentation of this observation Property type: Classification of type Geologist
Serial number | Assingining this number shall be done in a unique way on the server. Serial number is unique for each construction area (not unique across project) Serial number is an integer Serial number is not necessarily gap-free, or monotonous in any way but it is unique
Geometry | Defines location and shape of the mapping even Property type: Geometry Supported geometry types: Polygon, multi-polygon

Table 2: Properties on level 0 of the Observations property structure of this feature type


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Fractures

Last edited: 1/22/2018 9:14:06 AM

Sprickor

Property Identifying name | Description
FRACTUREGeometry Geometry Geometri | Defines location and shape of the fracture Property type: Geometry Supported geometry types: Multiline
FRACTUREPROGNOSIS Prognosis | If true defines that this collection element is a prognosis and not an actually observed characteristic.
FRACTUREDIPDIRECTION Dip direction Stupningsriktning | The dip direction is the azimuth of the direction the dip as projected to the horizontal, which is 90° off the strike angle. Property type: Numeric Default Value: null Validation rule: >= 0 and <=359
FRACTUREDIP Dip Stupning | The dip gives the steepest angle of the discontinuity plane relative to a horizontal plane. Property type: Numeric Default Value: null Validation rule: >= 0 and <=90
FRACTUREPERSISTENCE Persistence Uthållighet | Persistence of the Discontinuity Property type: Classification of type Persistence
FRACTUREAPERTURE Aperture / With Sprickvidd | Aperture of the fracture Property type: Classification of type Aperture / Width
FRACTUREINFILL Infill Sprickfyllning | Filling materials of the fracture Property type: Multiclassification of type Filling
FRACTUREJA Ja Ja | Property type: Numeric Display settings: ·Accepted ranges: 0.75;1;2;3;4;6;8;9;10;11;12;13;14;15;16;17;18;19;20
FRACTUREJACLASS Ja Class Ja Fall | Property type: Classification of type Ja class
FRACTUREJR Jr Jr | Property type: Numeric Display settings: ·Accepted ranges: 0.5;1;1.5;2;3;4
FRACTUREJRCLASS Jr Class Jr Fall | Property type: Classification of type Jr Class
FRACTUREWATERFLOW Water flow Vattenföring | Property type: Classification of type Water flow
FRACTURESPACING Spacing Sprickavstånd | Property type: Classification of type Spacing
FRACTURECOUNT Number of fractures Antal sprickor | Number of fractures in the fracture set Property type: Classification of type Discontinuity count
FRACTUREPARALLELFOLIATION Parallel to foliation Förskiffring | Defines if the fracture(s) are parallel to the foliation or not. Property type: Boolean
FRACTURECLAYALTERATION Clay alteration Leromvandling | Property type: Classification of type Clay alteration
FRACUTREPERSISTENT Persistent fracture Kraftig spricka | Property type: Boolean
FRACTURENOTES Notes Notering | General description of the afflux Property Type: Text Default Value: none Display Options: Multi line
FRACTURECOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
FRACTUREOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the discontinuities collection

Application specific configuration for MappRover

Setting | Value
Group | Geology
Bounding box rule | Mapping template, Mapping Event
Allow prognosis | yes

Table 2: Application specific configuration for MappRover

Agnostic styling

Fracture with given Dip

·Dip is show as number at the center of the line if dip between 15 - 80 and with a line

·Dip is show as double-point symbol if dip is between 80 and 90

·Dip is shown as crossing-line symbol if dip between 0 and 15

·Dip direction is encoded by placing the symbol and text at one specific side of the line

Label rule: Dip

If persisting fracture then use slash character (every 3rd meter)


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Weakness zones

Last edited: 1/22/2018 9:14:06 AM

Svaghetszoner

Property Identifying name | Description
WEAKNESZONEGeometry Geometry Geometri | Defines location and shape of the weakness zone Property type: Geometry Supported geometry types: Multipolygon, Multiline
WEAKNESSZONEPROGNOSIS Prognosis | If true defines that this collection element is a prognosis and not an actually observed characteristic.
WEAKNESSZONEDipDirection Dip direction Stupningsriktning | The dip direction is the azimuth of the direction the dip as projected to the horizontal, which is 90° off the strike angle. Property type: Numeric Default Value: null Validation rule: >= 0 and <=359
WEAKNESSZONEDIP Dip Stupning | The dip gives the steepest angle of the discontinuity plane relative to a horizontal plane. Property type: Numeric Default Value: null Validation rule: >= 0 and <=90
WEAKNESSZONEThickness Thickness Tjocklek | Classification of type weakness zone thickness
WEAKNESSZONEClayalteration Clay alteration Leromvandling | Classification of type clay alteration
WEAKNESSZONEJA Ja Ja | Property type: Numeric Display settings: ·Accepted ranges: 0.75;1;2;3;4;6;8;9;10;11;12;13;14;15;16;17;18;19;20
WEAKNESSZONEJACLASS Ja Class Ja Fall | Property type: Classification of type Ja class
WEAKNESSZONEJR Jr Jr | Property type: Numeric Display settings: ·Accepted ranges: 0.5;1;1.5;2;3;4
WEAKNESSZONEJRCLASS Jr Class Jr Fall | Property type: Classification of type Jr Class
WEAKNESSZONEWATERFLOW Water flow Vattenföring | Property type: Classification of type Water flow
WEAKNESSZONECOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
WEAKNESSZONEOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the weakness zones collection

Application specific configuration for MappRover

Setting | Value
Group | Geology
Bounding box rule | Mapping template, Mapping Event
Allow prognosis | yes

Table 2: Application specific configuration for MappRover

Agnostic visualization

Weakness zones can be either line geometries or polygon geometries. Line geometries are usually used for small weakness zones, polygon geometries for larger weakness zones.

Line Geometry

Labeling:

Dip value is show as number at the center of the line if dip between 15° - 80°, the unit is not shown. e.g. 35

Center Symbol Rule:

·Rotated line symbol. Dip is encoded by placing the symbol and text at one specific side of the line

Color

·Color: fixed (red)

·Linestyle fixed (solid with crosses every 1.5m)

·Linewidth (fixed)

Polygon Geometry

·Labeling: At first point of polygon

·Tick symbol: At first point of polygon

·Linestyle of outline: solid

·Filling: # pattern (fixed texture) or hatch patten.

Color: fixed (red)

Linestyle: fixed (solid)

Filling: Cross hatch

Linewidth: (fixed)


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Foliations

Last edited: 1/22/2018 9:14:06 AM

Property Identifying name | Description
FOLIATIONGeometry Geometry Geometri | Defines location and shape of the foliation Property type: Geometry Supported geometry types: Line / Multiline
FoliationPROGNOSIS Prognosis | If true defines that this collection element is a prognosis and not an actually observed characteristic.
FOLIATIONDipDirection Dip direction Stupningsriktning | The dip direction is the azimuth of the direction the dip as projected to the horizontal, which is 90° off the strike angle. Property type: Numeric Default Value: null Validation rule: >= 0 and <=359
FOLIATIONDIP Dip Stupning | The dip gives the steepest angle of the discontinuity plane relative to a horizontal plane. Property type: Numeric Default Value: null Validation rule: >= 0 and <=90
FoliationNOTES Notes Anmärkning | General description of the afflux Property Type: Text Default Value: none Display Options: Multi-line
FOLIATIONCOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
FOLIATIONOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the foliations collection

Application specific configuration for MappRover

Setting | Value
Group | Geology
Bounding box rule | Mapping template, Mapping Event
Allow prognosis | yes

Table 2: Application specific configuration for MappRover

Agnostic styling

Grey dashed line


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Geological units

Last edited: 1/22/2018 9:14:06 AM

Geological enheter

Property Identifying name | Description
GEOLOGICALUNITGeometry Geometry Geometri | Defines location and shape of the geological unit Property type: Geometry Supported geometry types: Multipolygon
GeologicalunitPROGNOSIS Prognosis | If true defines that this element is a prognosis and not an actually observed characteristic.
GEOLOGICALUNITDOMINATNROCKTYPE Dominant rock type Dominerande bergart | Property type: Classification of type Rock
GEOLOGICALUNITGRAINSIZE Dominant grain size Dominerande kornstorlek | Property type: Classification of type Grain Size
GEOLOGICALUNITWEATHERING Weathering/alteration Vittring/omvandling | Property type: Classification of type Weathering
GEOLOGICALUNITUCS UCS Tryckhållfasthet | Property type: Classification of type UCS
GEOLOGICALUNITCOMPLETE Complete Fullständig | If true the collection element is marked as completely documented. Property type: Boolean
GOLOGICALUNITOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the geological units collection

Application specific configuration for MappRover

Setting | Value
Group | Geology
Bounding box rule | Mapping template, Mapping Event, Objects of same type
Allow prognosis | yes

Table 2: Application specific configuration for MappRover

Agnostic visualization

Polygon: Texture filled

Texture images: Use 0.5 alpha background, else images as in pptx GEOLOGICALUNITDOMINATNROCKTYPE

Outline: Solid, same color as background but reduce hue GEOLOGICALUNITDOMINATNROCKTYPE


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Structure

Last edited: 1/22/2018 9:14:06 AM

Struktur

Property Identifying name | Description
STRUCTUREGeometry Geometry Geometri | Defines location and shape of the fractured rock mass Property type: Geometry Supported geometry types: Multipolygon
Structureprognosis Prognosis | If true defines that this element is a prognosis and not an actually observed characteristic.
STRUCTURERockmasstype Rock mass structure Bergmassans struktur | Property type: Classification of type Rock mass structure
STRUCTURECOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
STRUCTUREOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the fractured rock masses collection

Application specific configuration for MappRover

Setting | Value
Group | Geology
Bounding box rule | Mapping template, Mapping Event, Objects of same type
Allow prognosis | yes

Table 2: Application specific configuration for MappRover

Agnostic visualization

Color: Brown ??

Pattern filling based on STRUCTURERockmasstype (might be empty)

Border based on STRUCTURERockmasstype (might be transparent)

Borderstyle dashdot


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

RMRs

Last edited: 1/22/2018 9:14:06 AM

RMR

Property, Property Collection | Description
RMRGEOMETRY Geometry Geometri | Defines location and shape of the area for which the RMR is specified Property type: Geometry Supported geometry types: Multipolygon
RMRSTRENGTH 1 Strength 1 Hållfasthet | Rating of the strength of Intact Rock Material Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 15 Display Options: Decimals: 0
RMRSTRENGTHVARIATION Strengh variation Hållfasthet variation | Property type: string
RMRRQD 2 RQD 2 RQD | Rating of the Drill Core Quality Property type: Numeric Default Value: none Validation rule: ≥ 3 and ≤ 20 Display Options: Decimals: 0
RMRRQDVARIATION RQD variation RQD variation | Property type: string
RMRSPACING 3 Discontinuity spacing 3 Sprickavstånd | Rating of the Discontinuity spacing Property type: Numeric Default Value: none Validation rule: ≥ 5 and ≤ 20 Display Options: Decimals: 0
RMRSPACINGVARIATION Spacing variation Sprickavstånd variation | Property type: string
RMRDISCONTINUITYCONDITION 4 Discontinuity condition 4 Sprickegenskaper | Summary of all ratings for discontinuity Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 6 Display Options: Decimals: 0
RMRDISCONTINUITYCONDITIONVARIATION Dicontinuity condition variation Sprickegenskaper variation | Property type: string
RMRGROUNDWATER 5 Groundwater 5 Grundvatten | Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 15 Display Options: Decimals: 0
RMRGROUNDWATERVARIATION Ground water variation Grundvatten variation | Property type: string
RMRADJUSTMENT 6 Discontinuity orientation 6 Sprickorientering | Property type: Numeric Default Value: none Validation rule: ≥ -60 and ≤ 0 Display Options: Decimals: 0
RMRADJUSTMENTVARIATION Discontinuity orientation variation Sprickorientering variation | Property type: string
RMRBASIC RMR Basic RMR Bas | Basic RMR Calculated Property STRENGTH + RQD + SPACING + RMRDISCONTINUITYCONDITION + 15
RMRBASIC RMR RMR | Rock mass rating value Calculated Field Property type: Numeric Default Value: none STRENGTH + RQD + SPACING + RMRDISCONTINUITYCONDITION + DiscontinuityOrientationVARIATION
RMRCOMPLETE Complete Fullständig | If true the collection element is marked as completely documented. Property type: Boolean
RMROBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the RMRs collection

Application specific configuration for MappRover

Setting | Value
Group | Geology
Bounding box rule | Mapping template, Mapping Event, Objects of same type
Allow prognosis | no

Table 2: Application specific configuration for MappRover

Agnostic visualization

RMR polygons are shown as polygons with solid color filling and solid border.

Color of polygon filling and border are chosen according to the value of the (calculated) value of the RMR property. Table 3 shows the color code.

The transparency of the polygon filling depends on the value of the complete property. If complete is true transparency is 0.5 else transparency is 0.75.

The transparency of the polygon outline depends on the value of the complete property. If complete is true transparency is 0 else transparency is 0.5

Value range | Color name | Color value
0-20 | Red | RGB(255, 0, 0)
21-40 | Orange | RGB(255, 165, 0)
41-60 | Yellow | RGB(255, 255, 0)
61-80 | Green | RGB(0, 255, 0)
81-100 | Blue | RGB(0, 255, 255)

Table 3: Color coding of the RMR value


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Qs

Last edited: 1/22/2018 9:14:06 AM

What we input is numeric value. Calculated values are read only. Calculations are as-you-type.

Property, Property Collection | Description
QGEOMETRY Geometry Geometri | Defines location and shape of the discontinuity Property type: Geometry Supported geometry types: Polygon
QRQD RQD RQD | Designation of Rock Quality Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 100 Display Options: Decimals: 0
QRQDVARIATION RQD variation RQD variation | Property type: String
QJNBASIC Jn Bas Jn Bas | Joint set number Property type: Numeric Default Value: none Validation rule: ≥ 3 and ≤ 20 Display Options: Decimals: 1 Hide trailing zeros: true
QJNBASICVARIATION Jn Bas variation Jn Bas variation | Property type: String
JnBasClass Jn Bas Class Jn Bas Klass | Property Type: Classification of type Jn Class
QJNBASICNOTES Jn Bas Notes Jn Bas Notes | Property Type: String
QJNCORRECTION Jn Correction Jn Correction | Joint Set Correction Property type: Numeric Default Value: none Validation rule: ≥ 1 and ≤ 3 Display Options: Decimals: 0 Hide trailing zeros: true
QJNCORRECTIONNOTES Jn Correction notes Jn Correction notes | Property type: String
QJN Jn Jn | Joint set number (corrected) Calculated property. Calculated with formula: Jn = JnBasic*JnCorrection Property type: Numeric Default Value: none Validation rule: ≥ 0 and ≤ 6 Display Options: Decimals: 0 Hide trailing zeros: true
QJR Jr Jr | Joint Roughness number Property type: Numeric Default Value: none Validation rule: ≥ 0.5 and ≤ 5 Display Options: Decimals: 1 Hide trailing zeros: true
QJRVARIATION Jr variation Jr variation | Property Type: String
QJRNOTES Jr notes Jr notes | Property Type: String
QJA Ja Ja | Joint Alteration Number Property type: Numeric Default Value: none Validation rule: ≥ 0.05 and ≤ 20 Display Options: Decimals: 0 Hide trailing zeros: true
QJAVARIATION Ja variation Ja variation | Property Type: String
QJANOTES Ja Ja | Property Type: String
QJW Jw Jw | Joint Water Reduction Factor Property type: Numeric Default Value: none Validation rule: ≥ 0.05 and ≤ 1 Display Options: Decimals: 0 Hide trailing zeros: false
QJWVARIATION Jw variation Jw variation | Property Type: String
QJWNOTES Jw notes Jw notes | Property Type: String
QSRF SRF SRF | Stress reduction factor Property type: Numeric Default Value: none Validation rule: ≥ 0.5 and ≤ 200 Display Options: Decimals: 0 Hide trailing zeros: true
QSRFVARIATION SRF variation SRF variation | Property Type: String
QSRFNOTES | Property Type: String
QBAS QBas QBas | Property type: Numeric Calculated property. Calculated with formula: QBase = Max(RQD,10)/JnBas * Jr/Ja Default Value: none Validation rule: ≥ 0 and ≤ 15 Display Options: Decimals: 0
QQ Q Q | Property type: Numeric Calculated property. Calculated with formula: Q = (Max(RQD,10) / (JBas* JCorr)) * (Jr/Ja) * (Jw/SRF) Default Value: none
QCOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
QOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the Qs collection

Application specific configuration for MappRover

Setting | Value
Group | Geology
Bounding box rule | Mapping template, Mapping Event, Objects of same type
Allow prognosis | no

Table 2: Application specific configuration for MappRover

Agnostic visualization

Color accroding to Q value

> 10 blue

4-10 green

1-4 yellow

0.1-1 orange

<0.1 red

slightly transparent 0,5

Border non transparent but same color


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Water inflows

Last edited: 1/22/2018 9:14:06 AM

Vattenföring

Property Identifying name | Description
WATERINFLOWGeometry Geometry Geometri | Defines location and shape of the water inflow Property type: Geometry Supported geometry types: Point, Polygon
WATERinflowtype Type of inflow Typ av Vattenföring | Property type: Classification of type Influx type
WATERINFLOWESTIMATION Estimated inflow Uppskattat flöde | Property type: Numeric Default Value: null Validation rule: ≥0 Display unit: l/min
WATERINFLOWCOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
WATERINFLOWOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the water inflows collection

Application specific configuration for MappRover

Setting | Value
Group | Geology
Bounding box rule | Mapping template, Mapping Event
Allow prognosis | no

Table 2: Application specific configuration for MappRover

Agnostic visualization

Symbol according to classification (color)

Point color: Blue??


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Overbreaks

Last edited: 1/22/2018 9:14:06 AM

Bergutfall

Property Identifying name | Description
OVERBREAKGeometry Geometry Geometri | Defines location and shape of the discontinuity Property type: Geometry Supported geometry types: Polygon
OVERBREAKEstimatedVolume Estimated volume Uppskattat volym | Property type: Classification of type Overbreak volume
overbreakTYPE Type of overbreak Typ av utfall | Property type: Classification of type Overbreak type
OVERBREAKCOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
OVERBREAKOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the Overbreaks collection

Application specific configuration for MappRover

Setting | Value
Group | Geology
Bounding box rule | Mapping template, Mapping Event, Objects of same type
Allow prognosis | no

Table 2: Application specific configuration for MappRover

Agnostic visualization

Cloud line??

Change to line shape

hide line

Just display symbol

Color??


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Miscellaneous elements

Last edited: 1/22/2018 9:14:06 AM

Property Identifying name | Description
MISCELLANEOUSGEOMETRY Geometry Geometri | Defines location and shape of the discontinuity Property type: Geometry Supported geometry types: All
MISCELLANEOUSTitle Title Titel | A short title for the element Property type: String Validation rule: Length ≤ 50
MISCELLANEOUSDescription Description Beskrivning | A description for the element Property type: String
MISCELLANEOUSCOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
MISCELLANEOUSOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the Miscellaneous elements collection

Application specific configuration for MappRover

Setting | Value
Group | Geology
Bounding box rule | Mapping template, Mapping Event
Allow prognosis | yes

Table 2: Application specific configuration for MappRover

Agnostic visualization

·All have same color: we choose something distinctive: green color

·Show title as label

·Point: Some fixed font symbol

·Line: Dotted, Midpoint symbol, what is the midpointSymbol??

·Polygon: Dotted outline, midpoint symbol, Fill color?


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Prescribed spot bolts

Last edited: 1/22/2018 9:14:06 AM

Anvisad selektiv bultar

Property Identifying name | Description
SpotBOLTGeometry Geometry Geometri | Defines location and shape of the discontinuity Property type: Geometry Supported geometry types: Multipoint
SpotBOLTLENGTH Bolt length Bultlängd | Property type: Classification of type Rock bolt length
SpotBOLTTYPE Bolt type Bulttyp | Property type: Classification of type Rock bolt type
SpotBOLTCORROSIONPRO Corrosion protection class Korrosivitetsklass | Property type: Classification of type Corrosion protection class
SpotBOLTFACEPLATE Face plate Brickor | Defines whether a face plate shall be used for rock bolts. Property type: Boolean Default Value: null
SpotBOLTCOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
SpotBOLTOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the spot bolts collection

Application specific configuration for MappRover

Setting | Value
Group | Prescribed reinforcement
Bounding box rule | Mapping template, Mapping Event
Allow prognosis | no

Table 2: Application specific configuration for MappRover

Agnostic visualization

Based on SpotBOLTFACEPLATE

Color blue

Label with length


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Prescribed systematic bolting

Last edited: 1/22/2018 9:14:06 AM

Anvisad systematisk bultning

Property Identifying name | Description
Geometry Geometry Geometri | Defines location and shape of the area where systematic bolting was applied Property type: Geometry Supported geometry types: Multipolygon
BOLTLENGTH Bolt length Bultlängd | Property type: Classification of type Rock bolt length
BOLTTYPE Bolt type Bulttyp | Property type: Classification of type Rock bolt type
corrosivityClass Corrosivity class Korrosivitetsklass | Property type: Classification of type Corrosion protection class
FACEPLATE Face plate Brickor | Defines whether a face plate shall be used for rock bolts. Property type: Boolean Default Value: null
CENTERCENTERSPACING Spacing Bultavstånd | Property type: Classification of type Rock bolt spacing
FRACTURECOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
FRACTUREOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the systematic bolting areas collection

Application specific configuration for MappRover

Setting | Value
Group | Prescribed reinforcement
Bounding box rule | Mapping template, Mapping Event
Allow prognosis | no

Table 2: Application specific configuration for MappRover

Agnostic visualization

·Polygon with blue boundary

·Labeling is spacing and length

·Filling very transparent blue filling ?? 0.75??


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Prescribed shotcrete areas

Last edited: 1/22/2018 9:14:06 AM

Anvisad Sprutbetong

Property Identifying name | Description
PSHOTCRETEGeometry Geometry Geometri | Defines location and shape of the area to which the shotcrete was applied. Property type: Geometry Supported geometry types: Multipolygon
PSHOTCRETEThickness Thickness Tjocklek | Property type: Classification of type shotcrete thickness
PSHOTCRETEtype Type Typ | Property type: Classification of type Shotcrete type.
PSHOTCRETECOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
PSHOTCRETEOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the shotcrete areas collection

Application specific configuration for MappRover

Setting | Value
Group | Prescribed reinforcement
Bounding box rule | Mapping template, Mapping Event
Allow prognosis | no

Table 2: Application specific configuration for MappRover

Agnostic visualization

·Polygon with green boundary

·Filling according to shotcrete type: Texture

·Labeling is thickness

·Transparency 0.5


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Prescribed special reinforcements

Last edited: 1/22/2018 9:14:06 AM

Anvisad special Förstärkning

Property Identifying name | Description
Geometry Geometry Geometri | Defines location and shape of the special reinforcement. Property type: Geometry Supported geometry types: All
PSPECIALREINFORCEMENTTYPE Type of reinforcement Typ av förstärkning | Property type: Classification of type Reinforcement type
PSPECIALREINFORCEMENTDRAWINGNO Drawing number Ritningsnummer | Property type: String
PSPECIALREINFORCEMENTCOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
PSPECIALREINFORCEMENTOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the special reinforcements collection

Application specific configuration for MappRover

Setting | Value
Group | Prescribed reinforcement
Bounding box rule | Mapping template, Mapping Event
Allow prognosis | no

Table 2: Application specific configuration for MappRover

Agnostic visualization

·Polygon

oSpecific midpoint symbol based on "Type of reinforcement"

·Line

oSpecific midpoint symbol based on "Type of reinforcement"

·Point

osymbol based on "Type of reinforcement"


%Text%

Navigation: Appendices > Feature types > Tunneling > Geological mapping in tunnel 001 >

Prescribed reinforcement classes

Last edited: 1/22/2018 9:14:06 AM

Anvisad förstärkningsklasser

Property Identifying name | Description
PREINFORCEMENTCLASSGeometry Geometry Geometri | Defines location and shape of the area to which the reinforcement class is applied. Property type: Geometry Supported geometry types: Multipolygon
PREINFORCEMENTCLASS Reinforcement class Förstärkningsklass | Property type: Classification of type reinforcement class.
PREINFORCEMENTCLASSCOMPLETE Complete Fullständig | If true the collection element is considered as completely documented. Property type: Boolean
PREINFORCEMENTCLASSOBJECTNO No No. | Identifying number of the object within the observation. Property type: Numeric Default Value: null Validation rule: >= 0 Precision: 0

Table 1: Properties of the prescribed reinforcement classes collection

Application specific configuration for MappRover

Setting | Value
Group | Prescribed reinforcement
Bounding box rule | Mapping template, Mapping Event
Allow prognosis | no

Table 2: Application specific configuration for MappRover

Agnostic visualization

·Polygon with color based on PREINFORCEMENTCLASS

·Label shows name of Reinforcement class


Geological situation at headingface 001

Last edited: 10/5/2017 11:51:18 AM

Represents the geological situation at the heading face of a cyclical tunneling project. This feature type is tailored to the usual needs of a geological documentation in a hard rock environment.

Characteristic | Note
Name | Geological situation at headingface 001
Path | \Tunneling
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on observation
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | None

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

The property structure for type specific observation data of this feature type is a rich structure containing multiple collections. Figure 1 shows a graphical representation of this property structure.

Figure 1: The structure of the type specific data for observations.

Property Identifying name | Description
Round length ROUNDLENGTH | Describes the geologic situation for rounds in a tunnel drive. This feature type is tailored for use in a hard rock environment. Property type: Numeric Default Value: null Validation rule: >= 0
Round number ROUNDNUMBER | Number of the documented round. Property type: Numeric Default Value: null
General notes GENERALNOTES | General notes on the geologic situation. Property type: String
Notes on rock mass ROCKMASSNOTES | Notes on the surrounding rock mass. Property type: String
Notes on rock mass behaviour ROCKMASSBEHAVIOURNOTES | Notes on the behaviour of the surrounding rock mass on excavation. Property type: String
Rock notes ROCKNOTES | Notes on the rock. Property type: String
Heading face sketch HEADINGFACESKETCH | Sketch of the geological situation at the heading face of this round. Property type: Referenced Image
Sketch notes HEADINGFACESKETCHNOTES | Notes on the heading face sketch. Property type: String
Profile accuracy PROFILEACCURACY | Accuracy of the excavation in relation to the planned excavation geometry. Property type: Classification
Advance type ADVANCETYPE | Defines how the tunnel was excavated in this round. Property type: Classification

Table 2: Level 0 properties of this feature type.

Lithology

Documentation of lithological units of this round.

Property Identifying name | Description
Notes NOTES | General notes on the lithological unit. Property type: String
Color COLOR | Description of the color of the lithological unit. Property type: String
Geometry GEOMETRY | Geometry of the lithological unit on the heading face. Property type: Geometry
Dipping DIPPING | Dipping of the lithological unit. Property type: Numeric
Dipping direction DIPPINGDIRECTION | Line of greatest inclination to the horizontal. Property type: Numeric
Fragmentation FRAGMENTATION | Physical fragmentation of rocks. Property type: Classification
Water sensitivity WATERSENSITIVITY | Influence of water on the chemical and physical characteristics of the rock. Property type: Classification
Weathering WEATHERING | Encompasses all reactions of the rock to exegenous factors. Property type: Classification
Geologic unit GEOLOGICALUNIT | The geologic unit this lithological unit belongs to. Property type: Classification
Rock ROCK | The main rock type that characterizes this lithological unit. Property type: Classification
Rock strength ROCKSTRENGTH | Classification of the lithological unit regarding its strength on pressure, tensile strength, shearing strength, and other factors. Property type: Classification
Granular binging GRANULARBINDING | Classification of the lithological unit regarding the binding of granular material. Property type: Classification
Bedding BEDDING | Classification of the lithological unit regarding its bedding. Property type: Classification
Tectonic unit TECTONICUNIT | Tectonic unit this lithological unit is associated with. Property type: Classification
Stratigraphic unit STRATIGRAPHICUNIT | Stratigraphic unite this lithological unit is associated with. Property type: Classification
Formation strength FORMATIONSTRENGTH | Cohesiveness of rock that is totally divided by discontinuites. Property type: Classification
Intercalation INTERCALATION | Intercalation in rock. Property type: Classification

Table 3: Properties of elements in the lithology collection

Dicontinuities

Documentation of discontinuities in this round.

Property Identifying name | Description
Description DESCRIPTION | Description of the discontinuity unit. Property type: String
Location description LOCATIONDESCRIPTION | Description of position, shape and and orientation of the discontinuity unit. Property type: String
Geometry GEOMETRY | Geometry of this discontinuity unit on the heading face. Property type: Geometry
Dipping DIPPING | Dipping of the discontinuities in this unit. Property type: Numeric
Dipping direction DIPPINGDIRECTION | Line of greatest inclination to the horizontal Property type: Numeric
Genesis GENESIS | Classification of this discontinuity unit regarding to its genesis. Property type: Classification
Aperture APERTURE | Classification of this discontinuity unit regarding to the aperture. If the discontinuities are filled this describes the thickness of the filling. Property type: Classification
Spacing SPACING | Classification of this discontinuity unit regarding to the spacing between two discontinuities in this unit. Property type: Classification
Filling FILLING | Material that fills the discontinuity. Property type: Classification
Gouge GOUGE | Gouge that is found on the discontinuity. Property type: Classification
ASPERITY ASPERITY | Macroscopic description of the difference to a totally flat structure. Property type: Classification
ROUGHNESS ROUGHNESS | Microscopic description of the difference to a totally flat structure. Property type: Classification

Table 4: Properties of elements in the discontinuities collection

Water influx

Documentation of water influx.

Property Identifying name | Description
Notes NOTES | General notes on this water influx. Property type: String
Geometry GEOMETRY | Geometry of this influx at the heading face. Property type: Geometry
Leakage type LEAKAGETYPE | Property type: Classification
Leakage behaviour LEAKAGEBEHAVIOUR | Property type: Classification
Influx type INFLUXTYPE | Property type: Classification
Influx character INFLUXCHARACTER | Property type: Classification
Influx place INFLUXPLACE | Property type: Classification

Table 5: Properties of elements in the water influx collection

Rock mass

Documentation of the rock mass in this round.

Property Identifying name | Description
Geometry GEOMETRY | Geometry of this rock mass unit on the heading face. Property type: Geometry
Rock mass type ROCKMASSTYPE | Classification of this rock mass unit regarding its type. Property type: Classification
Rock mass behaviour ROCKMASSBEHAVIOUR | Classification of this rock mass unit regarding its behaviour on excavation. Property type: Classification

Table 6: Properties of elements in the rock mass collection

Samples

Documentation of samples

Property Identifying name | Description
Geometry GEOMETRY | Position of sample on the heading face. Property type: Geometry
Notes NOTES | General notes on the sample. Property type: String
Sample number SAMPLENUMBER | Number or ID of the sample. Property type: String
Sample type SAMPLETYPE | Classifies the sample according to its type. Property type: Classification

Table 7: Properties of elements in the samples collection


Geological situation at headingface 002

Last edited: 10/5/2017 11:51:18 AM

Represents the geological situation at the heading face of a cyclical tunneling project.

Characteristic | Note
Name | Geological situation at headingface 002
Path | \Tunneling
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on observation
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | None

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

The property structure for type specific observation data of this feature type is a rich structure containing multiple collections. Figure 1 shows a graphical representation of this property structure.

Figure 1: The structure of the type specific data for observations.

Property Identifying name | Description
Round length ROUNDLENGTH | Describes the geologic situation for rounds in a tunnel drive. This feature type is tailored for use in a hard rock environment. Property type: Numeric Default Value: null Validation rule: >= 0
Round number ROUNDNUMBER | Number of the documented round. Property type: Numeric Default Value: null
Cutdown area CUTDOWNAREA | Actually area of heading face Property type: Numeric (Unit is the unit of the axis reference system's LCS) Default Value: null
General notes GENERALNOTES | General notes on the geologic situation. Property type: String
Notes on rock mass ROCKMASSNOTES | Notes on the surrounding rock mass. Property type: String
Notes on rock mass behaviour ROCKMASSBEHAVIOURNOTES | Notes on the behaviour of the surrounding rock mass on excavation. Property type: String
Rock notes ROCKNOTES | Notes on the rock. Property type: String
Dicontinuity notes DISCONTINUITYNOTES | Notes on the discontinuities. Property type: String
Water notes WATERNOTES | Notes on water conditions. Property type: String
Heading face sketch HEADINGFACESKETCH | Sketch of the geological situation at the heading face of this round. Property type: Referenced Image
Sketch notes HEADINGFACESKETCHNOTES | Notes on the heading face sketch. Property type: String
Profile accuracy PROFILEACCURACY | Accuracy of the excavation in relation to the planned excavation geometry. Property type: Classification
Advance type ADVANCETYPE | Defines how the tunnel was excavated in this round. Property type: Classification
Excavation behaviour EXCAVATIONBEHAVIOUR | Behaviour of the rockmass on excavation Property type: Classification

Table 2: Level 0 properties of this feature type.

Lithology

Documentation of lithological units of this round.

Property Identifying name | Description
Notes NOTES | General notes on the lithological unit. Property type: String
Color COLOR | Description of the color of the lithological unit. Property type: String
Geometry GEOMETRY | Geometry of the lithological unit on the heading face. Property type: Geometry
Dipping DIPPING | Dipping of the lithological unit. Property type: Numeric
Dipping direction DIPPINGDIRECTION | Line of greatest inclination to the horizontal. Property type: Numeric
Fragmentation FRAGMENTATION | Physical fragmentation of rocks. Property type: Classification
Water sensitivity WATERSENSITIVITY | Influence of water on the chemical and physical characteristics of the rock. Property type: Classification
Weathering WEATHERING | Encompasses all reactions of the rock to exegenous factors. Property type: Classification
Geologic unit GEOLOGICALUNIT | The geologic unit this lithological unit belongs to. Property type: Classification
Rock ROCK | The main rock type that characterizes this lithological unit. Property type: Classification
Rock strength ROCKSTRENGTH | Classification of the lithological unit regarding its strength on pressure, tensile strength, shearing strength, and other factors. Property type: Classification
Granular binging GRANULARBINDING | Classification of the lithological unit regarding the binding of granular material. Property type: Classification
Bedding BEDDING | Classification of the lithological unit regarding its bedding. Property type: Classification
Tectonic unit TECTONICUNIT | Tectonic unit this lithological unit is associated with. Property type: Classification
Stratigraphic unit STRATIGRAPHICUNIT | Stratigraphic unite this lithological unit is associated with. Property type: Classification
Formation strength FORMATIONSTRENGTH | Cohesiveness of rock that is totally divided by discontinuites. Property type: Classification
Consistency CONSISTENCY | Property type: Classification
Plasticity PLASTICITY | Property type: Classification
Grainsize GRAINSIZE | Property type: Classification

Table 3: Properties of elements in the lithology collection

Dicontinuities

Documentation of discontinuities in this round.

Property Identifying name | Description
Description DESCRIPTION | Description of the discontinuity unit. Property type: String
Location description LOCATIONDESCRIPTION | Description of position, shape and and orientation of the discontinuity unit. Property type: String
Geometry GEOMETRY | Geometry of this discontinuity unit on the heading face. Property type: Geometry
Dipping DIPPING | Dipping of the discontinuities in this unit. Property type: Numeric
Dipping direction DIPPINGDIRECTION | Line of greatest inclination to the horizontal Property type: Numeric
Orientation estimated ORIENTATIONESTIMATED | Specifies if the orientation was measured or estimated Property type: Boolean Default value: false
Genesis GENESIS | Classification of this discontinuity unit regarding to its genesis. Property type: Classification
Persistence PERSISTENCE | Classification of this discontinuity unit regarding to its persistence. Property type: Classification
Aperture APERTURE | Classification of this discontinuity unit regarding to the aperture. If the discontinuities are filled this describes the thickness of the filling. Property type: Classification
Spacing SPACING | Classification of this discontinuity unit regarding to the spacing between two discontinuities in this unit. Property type: Classification
Filling FILLING | Material that fills the discontinuity. Property type: Classification
Gouge GOUGE | Gouge that is found on the discontinuity. Property type: Classification
ASPERITY ASPERITY | Macroscopic description of the difference to a totally flat structure. Property type: Classification
ROUGHNESS ROUGHNESS | Microscopic description of the difference to a totally flat structure. Property type: Classification

Table 4: Properties of elements in the discontinuities collection

Water influx

Documentation of water influx.

Property Identifying name | Description
Notes NOTES | General notes on this water influx. Property type: String
Geometry GEOMETRY | Geometry of this influx at the heading face. Property type: Geometry
Leakage type LEAKAGETYPE | Property type: Classification
Leakage behaviour LEAKAGEBEHAVIOUR | Property type: Classification
Influx type INFLUXTYPE | Property type: Classification
Influx character INFLUXCHARACTER | Property type: Classification
Influx place INFLUXPLACE | Property type: Classification
Influx at INFLUXAT | Property type: Classification
Temperature | Property type: Quantity
PH Value | Property type: Numeric
Conductivity | Property type: Quantity

Table 5: Properties of elements in the water influx collection

Samples

Documentation of samples

Property Identifying name | Description
Geometry GEOMETRY | Position of sample on the heading face. Property type: Geometry
Notes NOTES | General notes on the sample. Property type: String
Sample number SAMPLENUMBER | Number or ID of the sample. Property type: String
Sample type SAMPLETYPE | Classifies the sample according to its type. Property type: Classification

Table 6: Properties of elements in the samples collection


Geological situation at headingface 003

Last edited: 10/5/2017 11:51:18 AM

Represents the geological situation at the heading face of a cyclical tunneling project.

Characteristic | Note
Name | Geological situation at headingface 003
Path | \Tunneling
Feature type icon |
Feature type class | Group, can contain feature type: RMR
Spatial data support | Spatial support on observation
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | None

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

The property structure for type specific observation data of this feature type is a rich structure containing multiple collections. Figure 1 shows a graphical representation of this property structure.

Figure 1: The structure of the type specific data for observations.

Property Identifying name | Description
Round number ROUNDNUMBER | Number of the documented round. Property type: Numeric Default: null Decimal places: 0 Validation rule: ≥ 0
Round length ROUNDLENGTH | Actual length of the round Property type: Numeric Default: null Display unit: m Decimal places: 2 Validation rule: ≥ 0
Overbreak OVERBREAK | Volume of unplanned excavation. Property type: Numeric Default: null Display unit: m³ Decimal places: 2 Validation rule: ≥ 0
Advance type ADVANCETYPE | Property type: Classification of type Excavation type
Geological tendency GEOLOGICALTENDENCY | Property type: Classification of type Geological tendency
Water difficulty class WATERDIFFICULTYCLASS | Property type: Classification of type Water difficulty class
Rock Mass behavior type ROCKMASSBEHAVIORTYPE | Property type: Classification of type Rock Mass Behavior Type
GSI Structure GSI_STRUCTURE | Property type: Classification of type GSI Structure
GSI Surface condition GSI_SURFACECONDITION | Property type: Classification of type GSI Surface Condition
GSI GSI | GSI (Geological Strength Index) Property type: Numeric Default: null Decimals: 0 Validation rule: ≥ 0 and ≤ 100
Gestein ROCKNOTES | Notes on the rock. Property type: String
Notes on rock mass ROCKMASSNOTES | Notes on the surrounding rock mass. Property type: String
Notes on rock mass behavior ROCKMASSBEHAVIORNOTES | Notes on the behavior of the surrounding rock mass on excavation. Property type: String
Water notes WATERNOTES | Notes on water conditions. Property type: String
Hazardscenario HAZARDSCENARIO | Notes on possible hazards Property type: String
Discontinuity notes DISCONTINUITYNOTES | Notes on the discontinuities. Property type: String
Heading face sketch HEADINGFACESKETCH | Sketch of the geological situation at the heading face of this round. Property type: Referenced Image
Sketch notes HEADINGFACESKETCHNOTES | Notes on the heading face sketch. Property type: String
Block failure volume BLOCKFAILUREVOLUME | Volume of block failure Property type: Numeric Default: null Display unit: m³ Decimal places: 2 Validation rule: ≥ 0
Block failure weight BLOCKFAILUREWEIGHT | Weight of block failure Property type: Numeric Display unit: t Decimal places: 2 Default value: null Validation rule: ≥ 0

Table 2: Level 0 properties of this feature type.

Lithology

Documentation of lithological units of this round.

Property Identifying name | Description
Rock ROCK | The main rock type that characterizes this lithological unit. Property type: Classification of type rock
Color COLOR | Description of the color of the lithological unit. Property type: String
Shistosity SHISTOSITY | Property type: Classification of type Shistosity
Weathering WEATHERING | Property type: Classification of type Weathering
Water sensitivity WATERSENSITIVITY | Property type: Classification of type Water sensitivity
Schmidt Hammer Value [Mpa] SCHMIDTHAMMER | Compressive strength of rock determined with a Schmidt Hammer. Property type: Numeric Display unit: Mpa Default value: null Decimal places: 2 Validation rule: ≥ 0
Estimated UCS ESTIMATEDUCS | Estimated UCS (unconfined compressive strength) Property type: Classification of type Estimated UCS
Tectonic unit TECTONICUNIT | Property type: Classification of type Tectonical unit
Geologic unit GEOLOGICALUNIT | Property type: Classification of type Geologic unit
Stratigraphic unit STRATIGRAPHICUNIT | Property type: Classification of type Stratigraphic unit
Consistency CONSISTENCY | Property type: Classification of type Consistency
Grain cementation GRAINCEMENTATION | Property type: Classification of type Grain cementation
Grain shape GRAINSHAPE | Property type: Classification of type Grain shape
Grainsize GRAINSIZE | Property type: Classification of type Grain size
Texture TEXTURE | Property type: Classification of type Texture
Compaction COMPACTION | Property type: Classification of type Compaction.
Plasticity PLASTICITY | Property type: Classification of type Plasticity
Fragmentation FRAGMENTATION | Property type: Classification of type Fragmantation
Geometry GEOMETRY | Geometry of the lithological unit on the heading face. Property type: Geometry Allowed Geometry: Multi-polygon
Sample ID LITHOLOGYSAMPLEID | Id of the sample taken from this lithological unit Property type: String

Table 3: Properties in the lithology collection (level 1)

Property Identifying name | Description
Mineral MINERAL | Property type: Classification of type Mineral
Average length AVERAGELENGTH | Property type: Numeric type Length Default: null Decimals: 1 Display unit: mm Validation Rule: Validation rule: ≥ 0
Percentage MINERALPERCENTAGE | Property type: Numeric Default: null Decimals: 0 Validation rule: ≥ 0 and ≤ 100

Table 4: Properties in the minerals collection (sub collection of lithology, level 2)

Property Identifying name | Description
Rock mass type ROCKMASSTYPE | Property type: Classification of type Rock mass type
Percentage ROCKMASSPERCENTAGE | Property type: Numeric Default: null Decimals: 0 Validation rule: ≥ 0 and ≤ 100
Rockmass geometry ROCKMASSGEOMETRY | Geometry of the rockmass unit on the heading face. Property type: Geometry Allowed Geometry: Multi-polygon

Table 5: Properties in the rock mass collection (level 1)

Dicontinuities

Property Identifying name | Description
Genesis GENESIS | Property type: Classification of type Genesis
Strike STRIKE | Strike Property type: Numeric Default: null Decimals: 0 Display unit: ° (Degrees) Validation rule: ≥ 0 and ≤ 359
Dip DIP | Dipping of the discontinuities in this unit. Property type: Numeric Default: null Decimals: 0 Display unit: ° (Degrees) Validation rule: ≥ 0 and ≤ 90
Orientation estimated ORIENTATIONESTIMATED | Specifies if the orientation was measured or estimated Property type: Boolean Default value: null
Discontinuity group DISCONTINUITYGROUP | Property type: Classification of type Discontinuity group
Spacing SPACING | Property type: Classification of type Spacing
Persistence PERSISTENCE | Property type: Classification of type Persistence
Aperture APERTURE | Property type: Classification of type Aperture
Roughness ROUGHNESS | Property type: Classification of type Roughness
Filling FILLING | Property type: Classification of type Filling
Wall strength WALLSTRENGTH | Property type: Classification of type Wall strength
Description DESCRIPTION | Description of the discontinuity unit. Property type: String
Location description LOCATIONDESCRIPTION | Description of position, shape and and orientation of the discontinuity unit. Property type: String

Table 6: Properties in the discontinuities collection (level 1)

Water influx

Property Identifying name | Description
Identity IDENTITY | Name of the water influx Property type: String
Influx type INFLUXTYPE | Property type: Classification of type Influx type
Leakage type LEAKAGETYPE | Property type: Classification of type Leakage type
Leakage behavior LEAKAGEBEHAVIOR | Property type: Classification of type Leakage behavior
Influx place INFLUXAT | Property type: Classification of type Influx at
Notes INFLUXNOTES | General notes on this water influx. Property type: String
Delivery WATERINFLUXDELIVERY | Volumetric flow rate of the water influx. Property type: Numeric Default: null Decimals: 2 Display unit: l/s Validation rule: ≥ 0
Temperature WATERINFLUXTEMPERATURE | Temperature of the water. Property type: Numeric Default: null Decimals: 1 Display unit: ° (Degree Celsius) Validation rule: ≥ 0 and ≤ 100
PH-Value WATERINFLUXPHVALUE | PH-Value of the inflowing water. Property type: Numeric Default: null Decimals: 1 Display unit: dimensionless value Validation rule: ≥ 0 and ≤ 14
Conductivity WATERINFLUXCONDUCTIVITY | Conductivity of water Property type: Numeric Default: null Decimals: 0 Display unit: µS/m Validation rule: ≥ 0 and ≤ 14
Sample ID WATERINFLUXSAMPLEID | ID of a water sample taken from this source (if any) Property type: String

Table 7: Properties in the water influx collection (level 1)

Faults

Property Identifying name | Description
Fault type FAULTTYPE | Property type: Classification of type Fault type
Strike FAULTSTRIKE | Strike Property type: Numeric Default: null Decimals: 0 Display unit: ° (Degree) Validation rule: ≥ 0 and ≤ 359
Dip FAULTDIP | Dipping of the discontinuities in this unit. Property type: Numeric Default: null Decimals: 0 Display unit: ° (Degree) Validation rule: ≥ 0 and ≤ 90
Orientation estimated ORIENTATIONESTIMATED | Specifies if the orientation was measured or estimated Property type: Boolean Default value: null
Fault group FAULTGROUP | Property type: Classification of type Fault group
Thickness THICKNESS | Thickness of the fault, orthogonal to the fault plane Property type: Numeric Display unit: m Default: null Decimals: 1 Validation rule: ≥ 0
Effective length EFFECTIVELENGTH | Length of fault on tunnel axis Property type: Numeric Display unit: m Default: null Decimals: 1 Validation rule: ≥ 0
Fault rock FAULTROCK | Property type: Classification of type Rock
Weathering FAULTWEATHERING | Property type: Classification of type Weathering
Influx type FAULTWATERINFLUXTYPE | Property type: Classification of type Influx type
Harnisch Strike HARNISCHSTRIKE | Strike of harnisch Property type: Numeric Default: null Decimals: 0 Validation rule: ≥ 0 and ≤ 359
Harnisch Dip HANISCHDIP | Dipping of harnisch Property type: Numeric Default: null Decimals: 0 Validation rule: ≥ 0 and ≤ 90
Description FAULTDESCRIPTION | Textual description of the fault Property type: string

Table 8: Properties in the faults collection (level 1)


Geological situation at headingface 004

Last edited: 10/5/2017 11:51:18 AM

Represents the geological situation at the heading face of a cyclical tunneling project.

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


%Text%

Navigation: Appendices > Feature types > Tunneling >

Injection protocol

Last edited: 10/5/2017 11:51:24 AM

This feature type is used to document injection during the construction of a tunnel.

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


%Text%

Navigation: Appendices > Feature types > Tunneling >

Reinforcement

Last edited: 10/5/2017 11:51:34 AM

This feature type is used to record the reinforcement that is planned or actually used during a tunnel construction.

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


%Text%

Navigation: Appendices > Feature types > Tunneling >

Rock scaling

Last edited: 10/5/2017 11:51:34 AM

This feature type is used to document rock scaling works in a tunnel.

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


%Text%

Navigation: Appendices > Feature types > Tunneling >

Shotcrete application

Last edited: 10/5/2017 11:51:40 AM

This feature type is used to record the application of shotcrete during the construction of a tunnel.

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


TBM condensed data

Last edited: 10/5/2017 11:51:20 AM

This feature type is used to store statistically condensed TBM data.

Characteristic | Note
Name | TBM condensed data
Path | \Tunneling
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on observation
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for extended observation

Property Identifying name | Description
Duration DURATION | DESCRIPTION Property type: String
Start section START_SECTION | DESCRIPTION Property type: Numeric
End section END_SECTION | DESCRIPTION Property type: Numeric
Sample Count SAMPLE_COUNT | DESCRIPTION Property type: Numeric
Parameter 1 - Parameter 6 PARAMETER1 - PARAMETER6 | Value of parameters Property type: Numeric

Table 1: Properties in the type specific observation data


TBM raw data

Last edited: 10/5/2017 11:51:20 AM

This feature type is used to store TBM data.

Characteristic | Note
Name | TBM raw data
Path | \Tunneling
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on observation
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property Identifying name | Description
Status STATUS | Status of the machine Property type: Numeric
Length LENGTH | Length on axis the record represents Property type: Numeric
Duration DURATION | Duration of the record, in seconds. Property type: Numeric
Section SECTION | Section this record belongs to Property type: Numeric
Parameter 1 - Parameter 6 PARAMETER1 - PARAMETER6 | Value of parameters Property type: Numeric

Table 1: Properties in the type specific observation data


TBM status distribution

Last edited: 10/5/2017 11:51:20 AM

Represents the distribution of machine status calculated from the raw data over specified time or position intervals.

Characteristic | Note
Name | TBM status distribution
Path | \Tunneling
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on observation
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property Identifying name | Description
Duration DURATION | Summed duration of this status in seconds. Property type: Numeric
Start section START_SECTION | The TBM section number of the first record used for this group. Property type: Numeric
End section END_SECTION | The TBM section number of the last record used for this group. Property type: Numeric
Sample count SAMPLE_COUNT | The number of records in this status in the current group. Property type: Numeric

Table 1: Properties of ...

Status Durations

A collection that lists all status found in this group

Property Identifying name | Description
Status STATUS | The TBM status Property type: Numeric
Duration DURATION | The summed duration of all records in the current group with the current status - given in seconds. Property type: Numeric

Table 2: Properties of the durations collection


%Text%

Navigation: Appendices > Feature types > Tunneling >

Vibration

Last edited: 11/8/2017 10:15:02 AM

This feature type is used to record the vibration induced by the blasting or other works during a construction.

Characteristic | Note
Name | Vibration
Path | \Tunneling
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | Any
Allowed Geometry types | Any
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Value | A vibration value. Could be either mm/s (velocity) or m/s2 (acceleration) Property type: Number Default Value: null
Limit | Property type: Numeric Default Value: null
Distance | Property type: Numeric Default Value: null Display unit: m
Blast number | Property type: Text Default Value: null

Table 2: Properties and collections of the type specific observation data property structure


%Text%

Navigation: Appendices > Feature types > Tunneling >

Vibration-comfort

Last edited: 10/5/2017 11:51:46 AM

This feature type is used to record the vibration in buildings induced by the blasting or other works during a tunnel construction.

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


%Text%

Navigation: Appendices > Feature types > Tunneling >

Water afflux in tunnel

Last edited: 10/5/2017 11:51:20 AM

Represents a point of water influx in a tunnel. Usually used to monitor the water influx during construction.

Characteristic | Note
Name | Water afflux in tunnel
Path | \Tunneling
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
Position on profile POSITIONONPROFILE | Location of the water afflux on the tunnel profile, given as time. Property Type: Numeric Default Value: none Display Options: Display unit: h, Decimal places: 1
Leakage form LEAKAGEFORM | Classification of type: Leakage form

Table 2: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Flow Rate FLOWRATE | Quantity of type volumetric flow rate
Air temperature AIR_TEMPERATURE | Thermodynamic temperature of water Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -91.5 and Value ≤ 70.7 Display Options: Decimals: 2
Water temperature WATER_TEMPERATURE | Property Type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -50 and Value ≤ 200 Display Options: Decimals: 2
PH Value PH | Property type: Numeric Default Value: null Validation rule: Value ≥ 0 Value ≤ 14 Display Options: Decimals: 2
Conductivity CONDUCTIVITY | Property Type: Quantity of type electrical conductivity Default Value: null Default Unit: µS/m Validation rule: none Display Options: Decimals: 2
Description DESCRIPTION | General description of the afflux Property Type: Text Default Value: none Display Options: Multi line

Table 3: Properties and collections of the type specific observation data property structure


%Text%

Navigation: Appendices >

Classification types

Last edited: 10/5/2017 11:51:10 AM

This chapter gives an overview of the classification types available in Redbex. Many classification types are only used by a single feature, still classification types are defined independently which allows to link the same classification also to different feature types in future.


General

Last edited: 10/5/2017 11:51:10 AM

This chapter describes general classification types, i.e. classification types that are not associates with a specific application area or area of expertise.

Classification type name | Description
Event type | Classification of events. The characteristic of events chosen for this classification is up to the user.
Feature status | Classification to describe the status of a feature. E.g. planned, in operation, inactive etc.
Section type | Section type
Foundation category | Classifies the foundations of buildings according to the technical type of the foundation.
Positioning type | Classifies the way how the position (LSO) of a feature or observation was determined. E.g. GPS
Positioning accuracy | Classifies the accuracy of the recorded position (LSO).

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types >

Geology

Last edited: 10/5/2017 11:51:10 AM


%Text%

Navigation: Appendices > Classification types > Geology >

Discontinuities

Last edited: 10/5/2017 11:51:10 AM

Classification type name

Description

Aperture / Width

Aperture is the perpendicular distance between adjacent rock walls of a discontinuity, in which the intervening space is air or water filled.

Aperture is thereby distinguished from the width of a filled discontinuity. For a filled discontinuity the width describes also the thickness of the filling. [5]

This classification is used to describe a discontinuity of this discontinuity unit regarding to the aperture or width (whichever is fitting in the context where the classification is used)

Clay alteration

Clayband

Discontinuity count

Number of discontinuities (for a discontinuity set)

Discontinuity group

Classification for discontinuities according to common characteristics.

Exposureline

Filling

Filling is the material that separates the adjacent rock walls of a discontinuity and that is usually weaker than the parent rock. Typical filling materials are sand, silt, clay, breccia, gouge, mylonite. Also includes thin mineral coatings and healed discontinuities, e.g. quartz and calcite veins. [5]

This classification is used to classify the discontinuity filling.

Genesis

Classification of discontinuities according to their genesis.

Joint distance

Lineare-Type

Permeability

Classification for the discontinuity trace length as observed in an exposure. May give a crude measure of the areal extent or penetration length of a discontinuity. Termination in solid rock or against other discontinuities

Persistence

The persistence is the discontinuity trace length as observed in an exposure. May give a crude measure of the areal extent or penetration length of a discontinuity. Termination in solid rock or against other discontinuities reduces the persistence [5]

The persistence determines the possibilities of relative movement along a discontinuity in a soil or rock mass.

This classification type is used to classify discontinuities regarding to their persistence.

Rockbonding

Roughness

Classification of discontinuities according to the inherent surface roughness and waviness relative to the mean plane of a discontinuity. Both roughness and waviness contribute to the shear strength. Large scale waviness may also alter the dip locally. [5]

Shear

Spacing

Classification of discontinuities according to the perpendicular distance between adjacent discontinuities. Normally refers to the mean or modal spacing of a set of joints. [5]

Surface

Classification for the description of the macroscopic structure of the discontinuity wall, e.g. undulating

Wall strength

Classification of discontinuities according to the equivalent compression strength of the adjacent rock walls. May be lower than rock block strength due to weathering or alteration of the walls. An important component of shear strength if rock walls are in contact.[5]

Water flow

Classification of water inflow according to the amount of water flowing inside the discontinuity.

Weakness zone thickness

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types > Geology >

Faults

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Fault rock | Classification of the rock found in the fault.
Genesis | Classification of fault accoring to its genesis
Fault group | Classification for faults according to common characteristics.

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types > Geology >

Lithology

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Bedding | In geology a bed is the smallest division of a geologic formation or stratigraphic rock series marked by well-defined divisional planes (bedding planes) separating it from layers above and below. A bed is the smallest lithostratigraphic unit, usually ranging in thickness from a centimetre to several metres and distinguishable from beds above and below it. Beds can be differentiated in various ways, including rock or mineral type and particle size. The term is generally applied to sedimentary strata, but may also be used for volcanic flows or ash layers.
Bedding thickness | Classification for the thickness of beds
Carbonate content | Classification of carbonate content of rock
Cataclasit type | Classification of cataclasit. There are many varieties of cataclasite, classified by the percentage of the volume formed from the matrix.
Compaction | In sedimentology compaction refers to the process by which a sediment progressively loses its porosity due to the effects of loading. This forms part of the process of lithification. When a layer of sediment is originally deposited, it contains an open framework of particles with the pore space being usually filled with water. As more sediment is deposited above the layer, the effect of the increased loading is to increase the particle-to-particle stresses resulting in porosity reduction primarily through a more efficient packing of the particles and to a lesser extent through elastic compression and pressure solution.
Consistency | Classification of cohesive (fine grained) soil according to is quality as a functin water content.
Construction geol. unit |
UCS | Classification for description of the uniaxial compressive strength of rock.
Foliation | Classification of rock accordin to the planar structures that develop in metamorphic rocks as a result of directed pressure.
Foliation distance |
Formation |
Formation strength | Klassification of cohesiveness of rock that is totally divided by discontinuities. Cohesiveness is evaluated based on strengh (shear strenght, compressive strength, tensile strength)
Fragment composition |
Fragment form | Classification of the form of rock fragments
Fragment size | Klassifizierung der Größe von Kluftkörpern
Fragmentation | Classification of rock according to the weathering processes as a result of chemical reactions.
Geological unit |
Grain cementation | Classification for description of the cementation of mineral.
Grain shape | Classification of rocks according to the shape of the grain, which is defined as ratio of the 3 diameters and the radius of curvature.
Grain size | Classification of sediments and soil according to the size of its grains.
Granular binding |
Intercalation |
Karstification | Classification of calcareous rock according to its karstification
Minor rock |
Plasticity | Klassification of soil according to its possibility for permanent deformation, befor fracturing
Rock | Classification of aggregates of one or more minerals or mineraloids.
Rock strength | Klassification of rock according to its strength (pressure, tensile strength, shearing strength, and other factors)
Shistosity |
Stratigraphic unit | A stratigraphic unit is a volume of rock of identifiable origin and relative age range that is defined by the distinctive and dominant, easily mapped and recognizable petrographic, lithologic or paleontologic features (facies) that characterize it.
Tectonical unit | Large scale classification of rock according to its tectonic origin and characteristics
Texture | Classification for desription of the texture. Texture (or rock microstructure) in geology refers to the relationship between the materials of which a rock is composed.
Tropie |
Viscousness | Classification for describing the ciscousness of soil.
Water content | Classification to describe the water content of soil or loose sedimentary rock.
Water sensitivity | Classificatin of influence of water on the chemical and physical characteristics of the rock.
Weathering | Classification of reactions of the rock to exegenous factors.

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types > Geology >

Mineralogy

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Mineral | Classification of naturally occurring substances that are solid and inorganic representable by a chemical formula, usually abiogenic, and have an ordered atomic structure.

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types > Geology >

Rockmass

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
GSI Structure | Classification of rock mass according to its structure as used in the GSI (Geological Strength Index)
GSI Surface condition | Classification of rock mass according to its surface condition as used in the GSI (Geological Strength Index)
Rock mass behavior type | Categories of similar rock mass behavior in relation to deformation and failure
Rock mass structure | Classification of rock mass according to its structure / fracturing
Rock mass type | Large scale classification of rock

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types > Geology >

Samples

Last edited: 10/5/2017 11:51:34 AM

Classification type name | Description
Sample type | Classifies rock or soil samples according to the way that the samples were taken.

Table 1: Classification types


Geotechnics

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Rock quality | Classifies rock or soil samples according to the way that the samples were taken.
Injection type | Classifies different types of how injection is performed
Injection material | Classifies the types material injected
Ja class | Classes for Ja
Jr class | Classes for Jr

Table 1: Classification types


Navigation: Appendices > Classification types >

Hydrology

Last edited: 10/5/2017 11:51:10 AM


Ground water

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Aquifer type | Classifies an aquifer by its geological type. e.g. upper or lower aquifer.
Ground water magazine |
Drill hole type | Classifies the ground water measurement drill hole according to the technical equipment (pipe etc)
Filter type | Classifies the type of filter used within a borehole
Infiltration type |
Pipe dimension | Classifies the dimension of a pipe
Standard comment | Classification with a user defined meaning used to classify ground water level measurements in a drill hole
Tip type | Classifies the type of the tip of the ground water drilling

Table 1: Classification types


Water evidence securing

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Effectclass | Classifies the possibility that the project for which the monitoring is done has a negative effect on the water of this resource.
Land register authority | Authority that is responsible for registration of the lot on which the water resource is located
Measurability | Defines to what extent the water resource can be measured or monitored for securing evidence.
Spring type | Classifies the spring according to the geological situation
Utilization category | Specifies the category of utilization of this water resource.
Utilization Intensity | Defines the intensity of utilization of this water resource.
Utilization type | Defines how the water of this resource is used

Table 1: Classification types


Water afflux

Navigation: Appendices > Classification types > Hydrology >

Water evidence securing

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Basin type | Describes the type of basin in which the water is collected and where measurements take place
Site type | Describes in which kind of structure or site the feature is located e.g. garage, safety room etc.
Basin sealing type | Describes the sealing of the basin in which water is collected
Measurement type | Describes how the measuring is done

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types >

Laboratory analysis

Last edited: 10/30/2017 8:40:44 AM


%Text%

Navigation: Appendices > Classification types > Laboratory analysis >

General

Last edited: 10/5/2017 11:51:20 AM

Classification type name | Description
Laboratory analysis class | Classifies the feature according to different basic types of analyses.
Laboratory analysis reason | Specifies the reason why a laboratory analysis was conducted.
Laboratory analysis sampling type | Classifies the way how the analyzed sample was taken.
Laboratory analysis value type | Specifies the type of value that was estimated for a specific parameter during analysis. The value for a specific parameter in a laboratory result is not necessary a fixed numerical value but can be a value below or above detection limit or quantification limit. In this case this classification helps to classify the value into one of these categories.
Quality assessment | Classification for the assessment of the sample's quality

Table 1: Classification types


Air

Last edited: 10/5/2017 11:51:02 AM

Classification type name | Description
Air analysis parameter | Classification type for specifying the analyzed chemical or physical parameter.
Air sampling method | Classifies the methods used for generating an air sample
Air analysis result action | Classifies the actions that are performed based on the results of an air analysis

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types > Laboratory analysis >

Soil

Last edited: 10/5/2017 11:51:42 AM

Classification type name | Description
Soil analysis parameter | Classification type for specifying the analyzed chemical or physical parameter.
Soil analysis result action | Classifies the actions that are performed based on the results of a soil analysis
Soil sampling method | Classifies the methods used for generating a soil sample

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types > Laboratory analysis >

Water

Last edited: 10/5/2017 11:51:46 AM

Classification type name | Description
Water analysis parameter | Defines chemical, microbiological or other types of parameters for which values are estimated during a laboratory analysis. Examples: Calcium , Brom, Flourid, Mangan

Table 1: Classification types


LandRegister

Last edited: 10/30/2017 8:44:26 AM

Classification type name | Description
Detailtype | Classifies measured regions according to the type of measurement and therefore the level of detail.
Fondation category | Classifies buildings according to their foundations
County | Classifies features according to the county they belong to
Municipality | Classifies features according to the municipaliyty they belong to

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types >

Surveying

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Fixpoint | Classification for fix points used as reference for measurements.

Table 1: Classification types


Navigation: Appendices > Classification types >

Tunneling

Last edited: 10/5/2017 11:51:10 AM


General

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Excavation behavior | Classification for description of the excavate area during excavation and after excavation.
Excavation type | Classification for describing how a round in a tunnel was excavated, e.g. drill&blast, excavator etc.
Geological tendency | Classification for describing the overall geological tendency related to the construction works in a tunnel.
Overbreak type | Classification for describing the reason of an overbreak.
Overbreak volume | Classification for estimation of the volume of an overbreak.
Profile accuracy | Classification for description how accurate the effective excavated area fits the planned excavation area.
Reinforcement class | Classification for that describes what measures were taken or are to be taken during the construction of a tunnel to prevent a tunnel from collapsing.
Spanwidth | Classifies the spanwidth of the excavated area
TBM status | Status of a TBM
Water difficulty class | Classification used for describing the difficulties induced by water afflux in the tunnel. Often used for contractual matter.

Table 1: Classification types


Water

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Influx at | Classification of water afflux according to the geological feature where water appears, e.g. discontinuity, fault etc.
Influx character |
Influx point | Classification for roughly describing where the water emerges. E.g. Top heading, Floor, Total heading face
Influx type | Classification of water influx according to the way water emerges, e.g. dripping, flowing. Directly related to the amount of water.
Global influx type | Classification amount of water that emerges for a whole section of the tunnel
Leakage behavior | Classification of water influx according to the amount of water as a function over time. E.g. constant, decreasing, increasing.
Leakage form | Classification of water influx according to the geometrical form of influx, e.g. punctiform, laminar.

Table 1: Classification types


%Text%

Navigation: Appendices > Classification types > Tunneling >

Reinforcement

Last edited: 10/5/2017 11:51:10 AM

Classification type name | Description
Corrosion protection class |
Reinforcement class |
Reinforcement type |
Rock bolt length |
Rock bolt spacing | Center-Center Spacing applied when performing systematic bolting.
Rock bolt type |
Shotcrete application reason |
Shotcrete thickness |
Shotcrete type | Classifies different types of shotcrete based mixture, as well as chemical and physical attributes.

Table 1: Classification types


Sensor types

Last edited: 10/5/2017 11:51:40 AM

This part of the Reference Manual documents all sensor types currently supported by Redbex. Note all string characteristics of sensor types (name, description, path, etc.) are translated into all languages supported by the Application Server. This documentation lists names as English translations only.

Sensor types are structured in a sensor types tree, that is created from the path of the sensor type. The following chapters and sub-chapters reflect this structure.


General

Last edited: 10/5/2017 11:51:42 AM

Sensor types in this path can be used in many different application domains, and are allowed for many different feature types


General

Last edited: 10/5/2017 11:51:20 AM

The General sensor type is an extremely simple sensor type with no property structures defined. It may be used wherever just the name of a sensor is important and no additional data is known (or important) for the sensor.

Characteristic | Note
Unique ID |
Name | General
Path | \General
Sensor type icon |
Description | A general sensor
Available with | 3D Movement, 3D Movement (subsurface)

Property structure for type specific sensor data

This sensor type defines no property structure for type specific sensor data.

Property structure for chronological sensor data

This sensor type defines no property structure for chronological sensor data.

Property structure for observation configuration data

This sensor type defines no property structure for observation configuration data.


Human

Last edited: 10/5/2017 11:51:42 AM

Represents a human sensor, i.e. a person observing something.

Characteristic | Note
Unique ID | 8F5346E1-9BA9-4A1B-87EB-28D1F4C17BD6
Name | Human
Path | \General
Sensor type icon |
Description | Human sensor
Available with |

Table 1: Characteristics of this sensor type

Property structure for type specific sensor data

Property, Property Collection | Description
First Name | Property type: Text Default value: none Validation rule: none Display settings: single line
Last Name | Property type: Text Default value: none Validation rule: none Display settings: single line
Company | Property type: Text Default value: none Validation rule: none Display settings: single line
Email address | Property type: Text Default value: none Validation rule: none Display settings: single line
Telephone number | Property type: Text Default value: none Validation rule: none Display settings: single line
Description | Property type: Text Default value: none Validation rule: none Display settings: multi line

Table 2: Properties and collections in the type specific sensor data property structure

Property structure for chronological sensor data

Property, Property Collection | Description
Company | Property type: Text Default value: none Validation rule: none Display settings: single line
Position | Property type: Text Default value: none Validation rule: none Display settings: single line

Table 2: Properties and collections in the the chronological sensor data property structure

Property structure for observation configuration data

This sensor type defines no property structure for observation configuration.


%Text%

Navigation: Appendices >

String pattern matching

Last edited: 10/5/2017 11:51:42 AM

Different parts of Redbex support different syntax for comparing (matching) strings against patterns. This chapter describes each of these syntax.


%Text%

Navigation: Appendices > String pattern matching >

Simple wildcard patterns

Last edited: 10/5/2017 11:51:40 AM

Simple wildcard patterns are used in different parts of the Application Server for simple and easy to understand matching (=specifying and recognizing) strings of text.

Wildcard | Description
* | Matches zero one or more characters
? | Matches a single character

Table 1: Characters with special meaning in a simple wildcard patterns

Following rules apply to wildcard patterns

·There can be more than one wildcard in a single search pattern, and the two wildcard characters can be used in combination. For example, m*?? will match words starting with m with three or more characters.

·A pattern not including any wildcard character will search for an exact match.

·Wildcard patterns are case insensitive

·you want to search for * or ?, i.e. if you do not want those characters to be interpreted as wildcards you can escape them using the backslash \* or \?

·** is logically equal to *

Examples:

·m* will match every string with length ≥ 1 starting with m or M

·m?* will match every string with length ≥ 2 starting with m or M

·*m will match every string with length ≥ 1 ending with m or M

·?m will match every string with length 2 where the second character is m or M

·\?m will match the string ?m


%Text%

Navigation: Appendices > String pattern matching >

SQL-Wildcard expressions

Last edited: 10/5/2017 11:51:42 AM

SQL wildcard expressions provide simple but easy to understand and flexible means "matching" (specifying and recognizing) strings of text.

Wildcard character | Description | Example
% | Any string of zero or more characters. | %Name% matches AB Name as well as AB Name CD as well as Name1 %Name% does not math AB Nam CD %Name does not math Name CD
_ | Any single character. | Feature _ matches Feature 1 as well as feature A
[] | Any single character within the specified range ([a-f]) or set ([abcdef]). | Feature [12345] matches Feature 1, Feature 3 but not Feature 9
[^] | Any single character not within the specified range ([^a-f]) or set ([^abcdef]). | Feature [^A-M] matches Feature M to Feature Z but not Feature A to Feature M


Regular expressions

Last edited: 11/9/2017 8:05:48 AM

Regular expressions provide a concise and flexible means for "matching" (specifying and recognizing) strings of text, such as particular characters, words, or patterns of characters. Regular expressions are a mighty tool for processing (e.g. searching and filtering) text data. Redbex allows you to use regular expression in different places for filtering feature, validating properties and others more.

Providing a full documentation of regular expressions would go beyond the scope of this manual, however there are numerous online resources that document how to use regular expression. For starters we want to point you to the web pages of the Micosoft Developer Network that provide extensive documentation on regular expressions.

Note that there are some different flavors of regular expressions implementations. The application server is built on top of Microsoft's .NET Framework and therefore uses their implementation of regular expressions. Microsoft .NET Framework regular expressions incorporate the most popular features of other regular expression implementations such as those in Perl and awk. Designed to be compatible with Perl 5 regular expressions, .NET Framework regular expressions include features not yet seen in other implementations, such as right-to-left matching.

Following chapters provide only an incomplete quick reference to regular expressions.


Character escapes

Last edited: 10/5/2017 11:51:08 AM

The backslash character (\) in a regular expression indicates that the character that follows it either is a special character (as shown in the following table), or should be interpreted literally.

Escaped character | Description
\a | Matches a bell character, \u0007.
\b | In a character class, matches a backspace, \u0008.
\t | Matches a tab, \u0009.
\r | Matches a carriage return, \u000D. (\r is not equivalent to the newline character, \n.)
\v | Matches a vertical tab, \u000B.
\f | Matches a form feed, \u000C.
\n | Matches a new line, \u000A.
\e | Matches an escape, \u001B.
\ nnn | Uses octal representation to specify a character (nnn consists of two or three digits).
\x nn | Uses hexadecimal representation to specify a character (nn consists of exactly two digits).
\c X \c x | Matches the ASCII control character that is specified by X or x, where X or x is the letter of the control character.
\u nnnn | Matches a Unicode character by using hexadecimal representation (exactly four digits, as represented by nnnn).
\ | When followed by a character that is not recognized as an escaped character in this and other tables in this topic, matches that character. For example, \* is the same as\x2A, and \. is the same as \x2E. This allows the regular expression engine to disambiguate language elements (such as * or ?) and character literals (represented by \* or\?).

Table 1: Escaped characters

Pattern | Matches
\a | "\u0007" in "Error!" + '\u0007'
[\b]{3,} | "\b\b\b\b" in "\b\b\b\b"
(\w+)\t | "item1\t", "item2\t" in "item1\titem2\t"
\r\n(\w+) | "\r\nThese" in "\r\nThese are\ntwo lines."
[\v]{2,} | "\v\v\v" in "\v\v\v"
[\f]{2,} | "\f\f\f" in "\f\f\f"
\r\n(\w+) | "\r\nThese" in "\r\nThese are\ntwo lines."
\e | "\x001B" in "\x001B"
\w\040\w | "a b", "c d" in "a bc d"
\w\x20\w | "a b", "c d" in "a bc d"
\cC | "\x0003" in "\x0003" (Ctrl-C)
\w\u0020\w | "a b", "c d" in "a bc d"
\d+[\+-x\*]\d+\d+[\+-x\*\d+ | "2+2" and "3*9" in "(2+2) * 3*9"

Table 2: Examples for escaped characters


Character classes

Last edited: 10/5/2017 11:51:08 AM

A character class matches any one of a set of characters. Character classes include the language elements listed in table 1.

Character class | Description
[ character_group ] | Matches any single character in character_group. By default, the match is case-sensitive.
[^ character_group ] | Negation: Matches any single character that is not in character_group. By default, characters in character_group are case-sensitive.
[ first - last ] | Character range: Matches any single character in the range from first to last.
. | Wildcard: Matches any single character except \n. To match a literal period character (. or \u002E), you must precede it with the escape character (\.).
\p{ name } | Matches any single character in the Unicode general category or named block specified by name.
\P{ name } | Matches any single character that is not in the Unicode general category or named block specified by name.
\w | Matches any word character.
\W | Matches any non-word character.
\s | Matches any white-space character.
\S | Matches any non-white-space character.
\d | Matches any decimal digit.
\D | Matches any character other than a decimal digit.

Table 1: character classes

Pattern | Matches
[ae] | "a" in "gray" "a", "e" in "lane"
[^aei] | "r", "g", "n" in "reign"
[A-Z] | "A", "B" in "AB123"
a.e | "ave" in "nave" "ate" in "water"
\p{Lu} \p{IsCyrillic} | "C", "L" in "City Lights" "Д", "Ж" in "ДЖem"
\P{Lu} \P{IsCyrillic} | "i", "t", "y" in "City" "e", "m" in "ДЖem"
\w | "I", "D", "A", "1", "3" in "ID A1.3"
\W | " ", "." in "ID A1.3"
\w\s | "D " in "ID A1.3"
\s\S | " _" in "int __ctr"
\d | "4" in "4 = IV"
\D | " ", "=", " ", "I", "V" in "4 = IV"

Table 2: Examples for character classes


• Anchors

Navigation: Appendices > String pattern matching > Regular expressions >

Anchors

Last edited: 10/5/2017 11:51:02 AM

Anchors, or atomic zero-width assertions, cause a match to succeed or fail depending on the current position in the string, but they do not cause the engine to advance through the string or consume characters. The meta-characters listed in Table 1 are anchors.

Assertion | Description
^ | The match must start at the beginning of the string or line.
$ | The match must occur at the end of the string or before \n at the end of the line or string.
\A | The match must occur at the start of the string.
\Z | The match must occur at the end of the string or before \n at the end of the string.
\z | The match must occur at the end of the string.
\G | The match must occur at the point where the previous match ended.
\b | The match must occur on a boundary between a \w (alphanumeric) and a \W (non-alphanumeric) character.
\B | The match must not occur on a \b boundary.

Table 1: Anchors

Pattern | Matches
^\d{3} | "901" in "901-333-"
-\d{3}$ | "-333" in "-901-333"
\A\d{3} | "901" in "901-333-"
-\d{3}\Z | "-333" in "-901-333"
-\d{3}\z | "-333" in "-901-333"
\G\(\d\) | "(1)", "(3)", "(5)" in "(1)(3)(5)[7](9)"
\b\w+\s\w+\b | "them theme", "them them" in "them theme them them"
\Bend\w*\b | "ends", "ender" in "end sends endure lender"

Table 2: Examples for the usage of anchors


Grouping constructs

Last edited: 10/5/2017 11:51:22 AM

Grouping constructs delineate sub-expressions of a regular expression and typically capture substrings of an input string. Grouping constructs include the language elements listed in table 1.

Grouping construct | Description
( subexpression ) | Captures the matched sub-expression and assigns it a zero-based ordinal number.
(?< name >sub-expression) | Captures the matched sub-expression into a named group.
(?< name1 - name2 >sub-expression) | Defines a balancing group definition. For more information, see the "Balancing Group Definition" section in Grouping Constructs in Regular Expressions.
(?: sub-expression) | Defines a non-capturing group.
(?imnsx-imnsx:sub-expression) | Applies or disables the specified options within sub-expression. For more information, see Regular Expression Options.
(?= sub-expression) | Zero-width positive look-ahead assertion.
(?! sub-expression) | Zero-width negative look-ahead assertion.
(?<= sub-expression) | Zero-width positive look-behind assertion.
(?<! sub-expression) | Zero-width negative look-behind assertion.
(?> sub-expression) | Non-backtracking (or "greedy") sub-expression.

Table 1: Grouping constructs

Pattern | Matches
(\w)\1 | "ee" in "deep"
(?<double>\w)\k<double> | "ee" in "deep"
(((?'Open'\()[^\(\)]*)+((?'Close-Open'\))[^\(\)]*)+)*(?(Open)(?!))$ | "((1-3)*(3-1))" in "3+2^((1-3)*(3-1))"
Write(?:Line)? | "WriteLine" in "Console.WriteLine()"
A\d{2}(?i:\w+)\b | "A12xl", "A12XL" in "A12xl A12XL a12xl"
\w+(?=\.) | "is", "ran", and "out" in "He is. The dog ran. The sun is out."
\b(?!un)\w+\b | "sure", "used" in "unsure sure unity used"
(?<=19)\d{2}\b | "99", "50", "05" in "1851 1999 1950 1905 2003"
(?<!19)\d{2}\b | "51", "03" in "1851 1999 1950 1905 2003"
[13579](?>A+B+) | "1ABB", "3ABB", and "5AB" in "1ABB 3ABBC 5AB 5AC"

Table 2: Examples for grouping constructs


Quantifiers

Last edited: 10/5/2017 11:51:32 AM

A quantifier specifies how many instances of the previous element (which can be a character, a group, or a character class) must be present in the input string for a match to occur. Quantifiers include the language elements listed in the table 1.

Quantifier | Description
* | Matches the previous element zero or more times.
+ | Matches the previous element one or more times.
? | Matches the previous element zero or one time.
{ n } | Matches the previous element exactly n times.
{ n ,} | Matches the previous element at least n times.
{ n , m } | Matches the previous element at least n times, but no more than m times.
*? | Matches the previous element zero or more times, but as few times as possible.
+? | Matches the previous element one or more times, but as few times as possible.
?? | Matches the previous element zero or one time, but as few times as possible.
{ n }? | Matches the preceding element exactly n times.
{ n ,}? | Matches the previous element at least n times, but as few times as possible.
{ n , m }? | Matches the previous element between n and m times, but as few times as possible.

Table 1: Quantifiers

Pattern | Matches
\d*\.\d | ".0", "19.9", "219.9"
"be+" | "bee" in "been", "be" in "bent"
"rai?n" | "ran", "rain"
",\d{3}" | ",043" in "1,043.6", ",876", ",543", and ",210" in "9,876,543,210"
"\d{2,}" | "166", "29", "1930"
"\d{3,5}" | "166", "17668" "19302" in "193024"
\d*?\.\d | ".0", "19.9", "219.9"
"be+?" | "be" in "been", "be" in "bent"
"rai??n" | "ran", "rain"
",\d{3}?" | ",043" in "1,043.6", ",876", ",543", and ",210" in "9,876,543,210"
"\d{2,}?" | "166", "29", "1930"
"\d{3,5}?" | "166", "17668" "193", "024" in "193024"

Table 2: Examples for quantifiers


Alternation constructs

Last edited: 10/5/2017 11:51:02 AM

Alternation constructs modify a regular expression to enable either/or matching. These constructs include the language elements listed in table 1.

Alternation construct | Description
| | Matches any one element separated by the vertical bar (|) character.
(?( expression )yes | no ) | Matches yes if the regular expression pattern designated by expression matches; otherwise, matches the optional no part.expression is interpreted as a zero-width assertion.
(?( name ) yes |no ) | Matches yes if name, a named or numbered capturing group, has a match; otherwise, matches the optional no.

Table 1: Alternation constructs

Pattern | Matches
th(e|is|at) | "the", "this" in "this is the day. "
(?(A)A\d{2}\b|\b\d{3}\b) | "A10", "910" in "A10 C103 910"
(?<quoted>")?(?(quoted).+?"|\S+\s) | Dogs.jpg, "Yiska playing.jpg" in "Dogs.jpg "Yiska playing.jpg""

Table 2: Examples for alternation constructs


Regular expression options

Last edited: 10/5/2017 11:51:34 AM

You can specify options that control how the regular expression engine interprets a regular expression pattern.

·By using the miscellaneous construct (?imnsx-imnsx), where a minus sign (-) before an option or set of options turns those options off. For example, (?i-mn) turns case-insensitive matching (i) on, turns multiline mode (m) off, and turns unnamed group captures (n) off. The option applies to the regular expression pattern from the point at which the option is defined, and is effective either to the end of the pattern or to the point where another construct reverses the option.

·By using the grouping construct (?imnsx-imnsx:subexpression), which defines options for the specified group only.

The .NET Framework regular expression engine supports the following inline options.

Option | Description
i | Use case-insensitive matching.
m | Use multi-line mode. ^ and $ match the beginning and end of a line, instead of the beginning and end of a string.
n | Do not capture unnamed groups.
s | Use single-line mode.
x | Ignore un-escaped white space in the regular expression pattern.

Table 1: Regular expression options

Pattern | Matches
\b(?i)a(?-i)a\w+\b | "aardvark", "aaaAuto" in "aardvark AAAuto aaaAuto Adam breakfast"
For an example, see the "Multiline Mode" section in Regular Expression Options. |
For an example, see the "Explicit Captures Only" section in Regular Expression Options. |
For an example, see the "Single-line Mode" section in Regular Expression Options. |
\b(?x) \d+ \s \w+ | "1 aardvark", "2 cats" in "1 aardvark 2 cats IV centurions"

Table 2: Examples for regular expression options


Supported horizontal geographic coordinate systems

Last edited: 10/5/2017 11:51:42 AM

Table 1 shows the list of predefined horizontal geographic coordinate systems. Each of these coordinate systems is identified by an EPSG code. These codes for horizontal geographic coordinate systems are numbers assigned by the European Petroleum Survey Group (EPSG). Table 1 includes the exact definition of the supported horizontal geographic coordinate systems expressed in WKT syntax and as Proj4 definition.

The linear unit for measurement of length and area most geodetic coordinate system use the meter as measurement unit, however some also use different measurement units, table one shows the unit of measure for each geodetic coordinate system. Note that this linear unit is also predefined and cannot be changed by the user.

The famous WGS 84 geodetic coordinate system has EPSG code 4326.

EPSG

Name

WKT and Proj4 definition

Angular Unit

Linear Unit

4143

Abidjan 1987

GEOGCS["Abidjan 1987", DATUM["Abidjan 1987", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-124.76,53,466.79,0,0,0,0 +no_defs

°

m

4144

Kalianpur 1937

GEOGCS["Kalianpur 1937", DATUM["Kalianpur 1937", ELLIPSOID["Everest 1830 (1937 Adjustment)", 6377276.345, 300.8017]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377276.345 +b=6356075.41314024 +no_defs

°

m

4145

Kalianpur 1962

GEOGCS["Kalianpur 1962", DATUM["Kalianpur 1962", ELLIPSOID["Everest 1830 (1962 Definition)", 6377301.243, 300.8017255]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377301.243 +b=6356100.230165384 +no_defs

°

m

4146

Kalianpur 1975

GEOGCS["Kalianpur 1975", DATUM["Kalianpur 1975", ELLIPSOID["Everest 1830 (1975 Definition)", 6377299.151, 300.8017255]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377299.151 +b=6356098.145120132 +towgs84=295,736,257,0,0,0,0 +no_defs

°

m

4147

Hanoi 1972

GEOGCS["Hanoi 1972", DATUM["Hanoi 1972", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +towgs84=-17.51,-108.32,-62.39,0,0,0,0 +no_defs

°

m

4148

Hartebeesthoek94

GEOGCS["Hartebeesthoek94", DATUM["Hartebeesthoek94", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4149

CH1903

GEOGCS["CH1903", DATUM["CH1903", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +towgs84=674.374,15.056,405.346,0,0,0,0 +no_defs

°

m

4150

CH1903+

GEOGCS["CH1903+", DATUM["CH1903+", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +towgs84=674.374,15.056,405.346,0,0,0,0 +no_defs

°

m

4151

CHTRF95

GEOGCS["CHTRF95", DATUM["Swiss Terrestrial Reference Frame 1995", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4152

NAD83(HARN)

GEOGCS["NAD83(HARN)", DATUM["NAD83 (High Accuracy Regional Network)", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +no_defs

°

m

4153

Rassadiran

GEOGCS["Rassadiran", DATUM["Rassadiran", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-133.63,-157.5,-158.62,0,0,0,0 +no_defs

°

m

4154

ED50(ED77)

GEOGCS["ED50(ED77)", DATUM["European Datum 1950(1977)", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4155

Dabola 1981

GEOGCS["Dabola 1981", DATUM["Dabola 1981", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +towgs84=-83,37,124,0,0,0,0 +no_defs

°

m

4156

S-JTSK

GEOGCS["S-JTSK", DATUM["Jednotne Trigonometricke Site Katastralni", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4157

Mount Dillon

GEOGCS["Mount Dillon", DATUM["Mount Dillon", ELLIPSOID["Clarke 1858", 6378293.64520876, 294.260676369261]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378293.645208759 +b=6356617.987679838 +no_defs

°

Clarke's foot

4180

EST97

GEOGCS["EST97", DATUM["Estonia 1997", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4181

Luxembourg 1930

GEOGCS["Luxembourg 1930", DATUM["Luxembourg 1930", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-193,13.7,-39.3,-0.41,-2.933,2.688,0.43 +no_defs

°

m

4182

Azores Occidental 1939

GEOGCS["Azores Occidental 1939", DATUM["Azores Occidental Islands 1939", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4183

Azores Central 1948

GEOGCS["Azores Central 1948", DATUM["Azores Central Islands 1948", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-104,167,-38,0,0,0,0 +no_defs

°

m

4184

Azores Oriental 1940

GEOGCS["Azores Oriental 1940", DATUM["Azores Oriental Islands 1940", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-203,141,53,0,0,0,0 +no_defs

°

m

4188

OSNI 1952

GEOGCS["OSNI 1952", DATUM["OSNI 1952", ELLIPSOID["Airy 1830", 6377563.396, 299.3249646]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=airy +towgs84=482.5,-130.6,564.6,-1.042,-0.214,-0.631,8.15 +no_defs

°

m

4189

REGVEN

GEOGCS["REGVEN", DATUM["Red Geodesica Venezolana", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4190

POSGAR 98

GEOGCS["POSGAR 98", DATUM["Posiciones Geodesicas Argentinas 1998", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +no_defs

°

m

4191

Albanian 1987

GEOGCS["Albanian 1987", DATUM["Albanian 1987", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +no_defs

°

m

4192

Douala 1948

GEOGCS["Douala 1948", DATUM["Douala 1948", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-206.1,-174.7,-87.7,0,0,0,0 +no_defs

°

m

4193

Manoca 1962

GEOGCS["Manoca 1962", DATUM["Manoca 1962", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +towgs84=-70.9,-151.8,-41.4,0,0,0,0 +no_defs

°

m

4194

Qornoq 1927

GEOGCS["Qornoq 1927", DATUM["Qornoq 1927", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4195

Scoresbysund 1952

GEOGCS["Scoresbysund 1952", DATUM["Scoresbysund 1952", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=105,326,-102.5,0,0,0.814,-0.6 +no_defs

°

m

4196

Ammassalik 1958

GEOGCS["Ammassalik 1958", DATUM["Ammassalik 1958", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-45,417,-3.5,0,0,0.814,-0.6 +no_defs

°

m

4197

Garoua

GEOGCS["Garoua", DATUM["Garoua", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4198

Kousseri

GEOGCS["Kousseri", DATUM["Kousseri", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4199

Egypt 1930

GEOGCS["Egypt 1930", DATUM["Egypt 1930", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4200

Pulkovo 1995

GEOGCS["Pulkovo 1995", DATUM["Pulkovo 1995", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +no_defs

°

m

4201

Adindan

GEOGCS["Adindan", DATUM["Adindan", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4202

AGD66

GEOGCS["AGD66", DATUM["Australian Geodetic Datum 1966", ELLIPSOID["Australian National Spheroid", 6378160, 298.25]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=aust_SA +no_defs

°

m

4225

Corrego Alegre

GEOGCS["Corrego Alegre", DATUM["Corrego Alegre", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-206,172,-6,0,0,0,0 +no_defs

°

m

4227

Deir ez Zor

GEOGCS["Deir ez Zor", DATUM["Deir ez Zor", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +no_defs

°

m

4229

Egypt 1907

GEOGCS["Egypt 1907", DATUM["Egypt 1907", ELLIPSOID["Helmert 1906", 6378200, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=helmert +no_defs

°

m

4230

ED50

GEOGCS["ED50", DATUM["European Datum 1950", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4231

ED87

GEOGCS["ED87", DATUM["European Datum 1987", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4232

Fahud

GEOGCS["Fahud", DATUM["Fahud", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4236

Hu Tzu Shan

GEOGCS["Hu Tzu Shan", DATUM["Hu Tzu Shan", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-637,-549,-203,0,0,0,0 +no_defs

°

m

4237

HD72

GEOGCS["HD72", DATUM["Hungarian Datum 1972", ELLIPSOID["GRS 1967", 6378160, 298.247167427]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS67 +no_defs

°

m

4238

ID74

GEOGCS["ID74", DATUM["Indonesian Datum 1974", ELLIPSOID["Indonesian National Spheroid", 6378160, 298.247]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378160 +b=6356774.50408554 +no_defs

°

m

4239

Indian 1954

GEOGCS["Indian 1954", DATUM["Indian 1954", ELLIPSOID["Everest 1830 (1937 Adjustment)", 6377276.345, 300.8017]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377276.345 +b=6356075.41314024 +towgs84=217,823,299,0,0,0,0 +no_defs

°

m

4240

Indian 1975

GEOGCS["Indian 1975", DATUM["Indian 1975", ELLIPSOID["Everest 1830 (1937 Adjustment)", 6377276.345, 300.8017]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377276.345 +b=6356075.41314024 +no_defs

°

m

4241

Jamaica 1875

GEOGCS["Jamaica 1875", DATUM["Jamaica 1875", ELLIPSOID["Clarke 1880", 6378249.14480801, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.144808011 +b=6356514.966204134 +no_defs

°

Clarke's foot

4242

JAD69

GEOGCS["JAD69", DATUM["Jamaica 1969", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4243

Kalianpur 1880

GEOGCS["Kalianpur 1880", DATUM["Kalianpur 1880", ELLIPSOID["Everest (1830 Definition)", 6377299.36559538, 300.8017]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377299.36559538 +b=6356098.359005157 +no_defs

°

Indian foot

4244

Kandawala

GEOGCS["Kandawala", DATUM["Kandawala", ELLIPSOID["Everest 1830 (1937 Adjustment)", 6377276.345, 300.8017]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377276.345 +b=6356075.41314024 +towgs84=-97,787,86,0,0,0,0 +no_defs

°

m

4245

Kertau 1968

GEOGCS["Kertau 1968", DATUM["Kertau 1968", ELLIPSOID["Everest 1830 Modified", 6377304.063, 300.8017]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377304.063 +b=6356103.038993155 +towgs84=-11,851,5,0,0,0,0 +no_defs

°

m

4246

KOC

GEOGCS["KOC", DATUM["Kuwait Oil Company", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-294.7,-200.1,525.5,0,0,0,0 +no_defs

°

m

4247

La Canoa

GEOGCS["La Canoa", DATUM["La Canoa", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-273.5,110.6,-357.9,0,0,0,0 +no_defs

°

m

4248

PSAD56

GEOGCS["PSAD56", DATUM["Provisional South American Datum 1956", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4249

Lake

GEOGCS["Lake", DATUM["Lake", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4250

Leigon

GEOGCS["Leigon", DATUM["Leigon", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-130,29,364,0,0,0,0 +no_defs

°

m

4120

Greek

GEOGCS["Greek", DATUM["Greek", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4121

GGRS87

GEOGCS["GGRS87", DATUM["Greek Geodetic Reference System 1987", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=-199.87,74.79,246.62,0,0,0,0 +no_defs

°

m

4122

ATS77

GEOGCS["ATS77", DATUM["Average Terrestrial System 1977", ELLIPSOID["Average Terrestrial System 1977", 6378135, 298.257]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378135 +b=6356750.304921594 +no_defs

°

m

4123

KKJ

GEOGCS["KKJ", DATUM["Kartastokoordinaattijarjestelma (1966)", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4124

RT90

GEOGCS["RT90", DATUM["Rikets koordinatsystem 1990", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4127

Tete

GEOGCS["Tete", DATUM["Tete", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4128

Madzansua

GEOGCS["Madzansua", DATUM["Madzansua", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4129

Observatario

GEOGCS["Observatario", DATUM["Observatario", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4130

Moznet

GEOGCS["Moznet", DATUM["Moznet (ITRF94)", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,0,0,-0,-0,-0,0 +no_defs

°

m

4131

Indian 1960

GEOGCS["Indian 1960", DATUM["Indian 1960", ELLIPSOID["Everest 1830 (1937 Adjustment)", 6377276.345, 300.8017]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377276.345 +b=6356075.41314024 +no_defs

°

m

4132

FD58

GEOGCS["FD58", DATUM["Final Datum 1958", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4133

EST92

GEOGCS["EST92", DATUM["Estonia 1992", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.055,-0.541,-0.185,0.0183,-0.0003,-0.007,-0.014 +no_defs

°

m

4134

PDO Survey Datum 1993

GEOGCS["PDO Survey Datum 1993", DATUM["PDO Survey Datum 1993", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4135

Old Hawaiian

GEOGCS["Old Hawaiian", DATUM["Old Hawaiian", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4136

St. Lawrence Island

GEOGCS["St. Lawrence Island", DATUM["St. Lawrence Island", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4137

St. Paul Island

GEOGCS["St. Paul Island", DATUM["St. Paul Island", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4138

St. George Island

GEOGCS["St. George Island", DATUM["St. George Island", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4139

Puerto Rico

GEOGCS["Puerto Rico", DATUM["Puerto Rico", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +towgs84=11,72,-101,0,0,0,0 +no_defs

°

m

4141

Israel

GEOGCS["Israel", DATUM["Israel", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=-48,55,52,0,0,0,0 +no_defs

°

m

4142

Locodjo 1965

GEOGCS["Locodjo 1965", DATUM["Locodjo 1965", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-125,53,467,0,0,0,0 +no_defs

°

m

4274

Datum 73

GEOGCS["Datum 73", DATUM["Datum 73", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4275

NTF

GEOGCS["NTF", DATUM["Nouvelle Triangulation Francaise", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +towgs84=-168,-60,320,0,0,0,0 +no_defs

°

m

4276

NSWC 9Z-2

GEOGCS["NSWC 9Z-2", DATUM["NSWC 9Z-2", ELLIPSOID["NWL 9D", 6378145, 298.25]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS66 +no_defs

°

m

4277

OSGB 1936

GEOGCS["OSGB 1936", DATUM["OSGB 1936", ELLIPSOID["Airy 1830", 6377563.396, 299.3249646]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=airy +datum=OSGB36 +no_defs

°

m

4278

OSGB70

GEOGCS["OSGB70", DATUM["OSGB 1970 (SN)", ELLIPSOID["Airy 1830", 6377563.396, 299.3249646]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=airy +no_defs

°

m

4279

OS(SN)80

GEOGCS["OS(SN)80", DATUM["OS (SN) 1980", ELLIPSOID["Airy 1830", 6377563.396, 299.3249646]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=airy +no_defs

°

m

4280

Padang

GEOGCS["Padang", DATUM["Padang 1884", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4281

Palestine 1923

GEOGCS["Palestine 1923", DATUM["Palestine 1923", ELLIPSOID["Clarke 1880 (Benoit)", 6378300.789, 293.466315538981]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378300.789 +b=6356566.435 +towgs84=-275.722,94.7824,340.894,-8.001,-4.42,-11.821,1 +no_defs

°

m

4282

Pointe Noire

GEOGCS["Pointe Noire", DATUM["Congo 1960 Pointe Noire", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +no_defs

°

m

4283

GDA94

GEOGCS["GDA94", DATUM["Geocentric Datum of Australia 1994", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4284

Pulkovo 1942

GEOGCS["Pulkovo 1942", DATUM["Pulkovo 1942", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +no_defs

°

m

4285

Qatar 1974

GEOGCS["Qatar 1974", DATUM["Qatar 1974", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4286

Qatar 1948

GEOGCS["Qatar 1948", DATUM["Qatar 1948", ELLIPSOID["Helmert 1906", 6378200, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=helmert +no_defs

°

m

4288

Loma Quintana

GEOGCS["Loma Quintana", DATUM["Loma Quintana", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4289

Amersfoort

GEOGCS["Amersfoort", DATUM["Amersfoort", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4292

Sapper Hill 1943

GEOGCS["Sapper Hill 1943", DATUM["Sapper Hill 1943", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-355,21,72,0,0,0,0 +no_defs

°

m

4293

Schwarzeck

GEOGCS["Schwarzeck", DATUM["Schwarzeck", ELLIPSOID["Bessel Namibia (GLM)", 6377483.86528042, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bess_nam +no_defs

°

German legal meter

4295

Serindung

GEOGCS["Serindung", DATUM["Serindung", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4297

Tananarive

GEOGCS["Tananarive", DATUM["Tananarive 1925", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-189,-242,-91,0,0,0,0 +no_defs

°

m

4298

Timbalai 1948

GEOGCS["Timbalai 1948", DATUM["Timbalai 1948", ELLIPSOID["Everest 1830 (1967 Definition)", 6377298.556, 300.8017]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=evrstSS +no_defs

°

m

4299

TM65

GEOGCS["TM65", DATUM["TM65", ELLIPSOID["Airy Modified 1849", 6377340.189, 299.3249646]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377340.189 +b=6356034.447938534 +no_defs

°

m

4300

TM75

GEOGCS["TM75", DATUM["Geodetic Datum of 1965", ELLIPSOID["Airy Modified 1849", 6377340.189, 299.3249646]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377340.189 +b=6356034.447938534 +no_defs

°

m

4301

Tokyo

GEOGCS["Tokyo", DATUM["Tokyo", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4302

Trinidad 1903

GEOGCS["Trinidad 1903", DATUM["Trinidad 1903", ELLIPSOID["Clarke 1858", 6378293.64520876, 294.260676369261]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378293.645208759 +b=6356617.987679838 +no_defs

°

Clarke's foot

4303

TC(1948)

GEOGCS["TC(1948)", DATUM["Trucial Coast 1948", ELLIPSOID["Helmert 1906", 6378200, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=helmert +no_defs

°

m

4304

Voirol 1875

GEOGCS["Voirol 1875", DATUM["Voirol 1875", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +towgs84=-73,-247,227,0,0,0,0 +no_defs

°

m

4306

Bern 1938

GEOGCS["Bern 1938", DATUM["Bern 1938", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4307

Nord Sahara 1959

GEOGCS["Nord Sahara 1959", DATUM["Nord Sahara 1959", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4308

RT38

GEOGCS["RT38", DATUM["Stockholm 1938", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4309

Yacare

GEOGCS["Yacare", DATUM["Yacare", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-155,171,37,0,0,0,0 +no_defs

°

m

4310

Yoff

GEOGCS["Yoff", DATUM["Yoff", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +no_defs

°

m

4311

Zanderij

GEOGCS["Zanderij", DATUM["Zanderij", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-265,120,-358,0,0,0,0 +no_defs

°

m

4312

MGI

GEOGCS["MGI", DATUM["Militar-Geographische Institut", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +no_defs

°

m

4313

Belge 1972

GEOGCS["Belge 1972", DATUM["Reseau National Belge 1972", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=106.869,-52.2978,103.724,-0.33657,0.456955,-1.84218,1 +no_defs

°

m

4314

DHDN

GEOGCS["DHDN", DATUM["Deutsches Hauptdreiecksnetz", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +datum=potsdam +no_defs

°

m

4315

Conakry 1905

GEOGCS["Conakry 1905", DATUM["Conakry 1905", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +towgs84=-23,259,-9,0,0,0,0 +no_defs

°

m

4316

Dealul Piscului 1933

GEOGCS["Dealul Piscului 1933", DATUM["Dealul Piscului 1933", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4317

Dealul Piscului 1970

GEOGCS["Dealul Piscului 1970", DATUM["Dealul Piscului 1970", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +no_defs

°

m

4318

NGN

GEOGCS["NGN", DATUM["National Geodetic Network", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=-3.2,-5.7,2.8,0,0,0,0 +no_defs

°

m

4319

KUDAMS

GEOGCS["KUDAMS", DATUM["Kuwait Utility", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +no_defs

°

m

4322

WGS 72

GEOGCS["WGS 72", DATUM["World Geodetic System 1972", ELLIPSOID["WGS 72", 6378135, 298.26]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS72 +no_defs

°

m

4324

WGS 72BE

GEOGCS["WGS 72BE", DATUM["WGS 72 Transit Broadcast Ephemeris", ELLIPSOID["WGS 72", 6378135, 298.26]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS72 +towgs84=0,0,1.9,0,0,0.814,-0.38 +no_defs

°

m

4695

Katanga 1955

GEOGCS["Katanga 1955", DATUM["Katanga 1955", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4696

Kasai 1953

GEOGCS["Kasai 1953", DATUM["Kasai 1953", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4697

IGC 1962 6th Parallel South

GEOGCS["IGC 1962 6th Parallel South", DATUM["IGC 1962 Arc of the 6th Parallel South", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4698

IGN 1962 Kerguelen

GEOGCS["IGN 1962 Kerguelen", DATUM["IGN 1962 Kerguelen", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=145,-187,103,0,0,0,0 +no_defs

°

m

4699

Le Pouce 1934

GEOGCS["Le Pouce 1934", DATUM["Le Pouce 1934", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-770.1,158.4,-498.2,0,0,0,0 +no_defs

°

m

4700

IGN Astro 1960

GEOGCS["IGN Astro 1960", DATUM["IGN Astro 1960", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4701

IGCB 1955

GEOGCS["IGCB 1955", DATUM["Institut Geographique du Congo Belge 1955", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-79.9,-158,-168.9,0,0,0,0 +no_defs

°

m

4702

Mauritania 1999

GEOGCS["Mauritania 1999", DATUM["Mauritania 1999", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4703

Mhast 1951

GEOGCS["Mhast 1951", DATUM["Missao Hidrografico Angola y Sao Tome 1951", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4704

Mhast (onshore)

GEOGCS["Mhast (onshore)", DATUM["Mhast (onshore)", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4705

Mhast (offshore)

GEOGCS["Mhast (offshore)", DATUM["Mhast (offshore)", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4706

Egypt Gulf of Suez S-650 TL

GEOGCS["Egypt Gulf of Suez S-650 TL", DATUM["Egypt Gulf of Suez S-650 TL", ELLIPSOID["Helmert 1906", 6378200, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=helmert +towgs84=-146.21,112.63,4.05,0,0,0,0 +no_defs

°

m

4707

Tern Island 1961

GEOGCS["Tern Island 1961", DATUM["Tern Island 1961", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=114,-116,-333,0,0,0,0 +no_defs

°

m

4708

Cocos Islands 1965

GEOGCS["Cocos Islands 1965", DATUM["Cocos Islands 1965", ELLIPSOID["Australian National Spheroid", 6378160, 298.25]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=aust_SA +towgs84=-491,-22,435,0,0,0,0 +no_defs

°

m

4709

Iwo Jima 1945

GEOGCS["Iwo Jima 1945", DATUM["Iwo Jima 1945", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=145,75,-272,0,0,0,0 +no_defs

°

m

4710

St. Helena 1971

GEOGCS["St. Helena 1971", DATUM["St. Helena 1971", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-320,550,-494,0,0,0,0 +no_defs

°

m

4711

Marcus Island 1952

GEOGCS["Marcus Island 1952", DATUM["Marcus Island 1952", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=124,-234,-25,0,0,0,0 +no_defs

°

m

4712

Ascension Island 1958

GEOGCS["Ascension Island 1958", DATUM["Ascension Island 1958", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-205,107,53,0,0,0,0 +no_defs

°

m

4713

Ayabelle Lighthouse

GEOGCS["Ayabelle Lighthouse", DATUM["Ayabelle Lighthouse", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-79,-129,145,0,0,0,0 +no_defs

°

m

4673

CI1979

GEOGCS["CI1979", DATUM["Chatham Islands Datum 1979", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=174.05,-25.49,112.57,-0,-0,0.554,0.2263 +no_defs

°

m

4674

SIRGAS 2000

GEOGCS["SIRGAS 2000", DATUM["Sistema de Referencia Geocentrico para America del Sur 2000", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4675

Guam 1963

GEOGCS["Guam 1963", DATUM["Guam 1963", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +towgs84=-100,-248,259,0,0,0,0 +no_defs

°

m

4676

Vientiane 1982

GEOGCS["Vientiane 1982", DATUM["Vientiane 1982", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +no_defs

°

m

4677

Lao 1993

GEOGCS["Lao 1993", DATUM["Lao 1993", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +no_defs

°

m

4678

Lao 1997

GEOGCS["Lao 1997", DATUM["Lao National Datum 1997", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +towgs84=44.585,-131.212,-39.544,0,0,0,0 +no_defs

°

m

4679

Jouik 1961

GEOGCS["Jouik 1961", DATUM["Jouik 1961", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-80.01,253.26,291.19,0,0,0,0 +no_defs

°

m

4680

Nouakchott 1965

GEOGCS["Nouakchott 1965", DATUM["Nouakchott 1965", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=124.5,-63.5,-281,0,0,0,0 +no_defs

°

m

4682

Gulshan 303

GEOGCS["Gulshan 303", DATUM["Gulshan 303", ELLIPSOID["Everest 1830 (1937 Adjustment)", 6377276.345, 300.8017]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377276.345 +b=6356075.41314024 +no_defs

°

m

4683

PRS92

GEOGCS["PRS92", DATUM["Philippine Reference System 1992", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +towgs84=-127.62,-67.24,-47.04,-3.068,4.903,1.578,-1.06 +no_defs

°

m

4684

Gan 1970

GEOGCS["Gan 1970", DATUM["Gan 1970", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-133,-321,50,0,0,0,0 +no_defs

°

m

4686

MAGNA-SIRGAS

GEOGCS["MAGNA-SIRGAS", DATUM["Marco Geocentrico Nacional de Referencia", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4687

RGPF

GEOGCS["RGPF", DATUM["Reseau Geodesique de la Polynesie Francaise", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +no_defs

°

m

4688

Fatu Iva 72

GEOGCS["Fatu Iva 72", DATUM["Fatu Iva 72", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=347.103,1078.12,2623.92,-33.8875,70.6773,-9.3943,186.074 +no_defs

°

m

4689

IGN63 Hiva Oa

GEOGCS["IGN63 Hiva Oa", DATUM["IGN63 Hiva Oa", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4690

Tahiti 79

GEOGCS["Tahiti 79", DATUM["Tahiti 79", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4691

Moorea 87

GEOGCS["Moorea 87", DATUM["Moorea 87", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=215.525,149.593,176.229,-3.2624,-1.692,-1.1571,10.4773 +no_defs

°

m

4692

Maupiti 83

GEOGCS["Maupiti 83", DATUM["Maupiti 83", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=217.037,86.959,23.956,0,0,0,0 +no_defs

°

m

4693

Nakhl-e Ghanem

GEOGCS["Nakhl-e Ghanem", DATUM["Nakhl-e Ghanem", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,-0.15,0.68,0,0,0,0 +no_defs

°

m

4694

POSGAR 94

GEOGCS["POSGAR 94", DATUM["Posiciones Geodesicas Argentinas 1994", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4251

Liberia 1964

GEOGCS["Liberia 1964", DATUM["Liberia 1964", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-90,40,88,0,0,0,0 +no_defs

°

m

4252

Lome

GEOGCS["Lome", DATUM["Lome", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +no_defs

°

m

4253

Luzon 1911

GEOGCS["Luzon 1911", DATUM["Luzon 1911", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4254

Hito XVIII 1963

GEOGCS["Hito XVIII 1963", DATUM["Hito XVIII 1963", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4255

Herat North

GEOGCS["Herat North", DATUM["Herat North", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-333,-222,114,0,0,0,0 +no_defs

°

m

4256

Mahe 1971

GEOGCS["Mahe 1971", DATUM["Mahe 1971", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=41,-220,-134,0,0,0,0 +no_defs

°

m

4257

Makassar

GEOGCS["Makassar", DATUM["Makassar", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +towgs84=-587.8,519.75,145.76,0,0,0,0 +no_defs

°

m

4258

ETRS89

GEOGCS["ETRS89", DATUM["European Terrestrial Reference System 1989", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +no_defs

°

m

4259

Malongo 1987

GEOGCS["Malongo 1987", DATUM["Malongo 1987", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4261

Merchich

GEOGCS["Merchich", DATUM["Merchich", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +towgs84=31,146,47,0,0,0,0 +no_defs

°

m

4262

Massawa

GEOGCS["Massawa", DATUM["Massawa", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +towgs84=639,405,60,0,0,0,0 +no_defs

°

m

4263

Minna

GEOGCS["Minna", DATUM["Minna", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4265

Monte Mario

GEOGCS["Monte Mario", DATUM["Monte Mario", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4266

M'poraloko

GEOGCS["M'poraloko", DATUM["M'poraloko", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +no_defs

°

m

4267

NAD27

GEOGCS["NAD27", DATUM["North American Datum 1927", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +datum=NAD27 +no_defs

°

m

4268

NAD27 Michigan

GEOGCS["NAD27 Michigan", DATUM["NAD Michigan", ELLIPSOID["Clarke 1866 Michigan", 6378450.0475489, 294.978697164674]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378450.047548896 +b=6356826.621488444 +no_defs

°

US survey foot

4269

NAD83

GEOGCS["NAD83", DATUM["North American Datum 1983", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +datum=NAD83 +no_defs

°

m

4270

Nahrwan 1967

GEOGCS["Nahrwan 1967", DATUM["Nahrwan 1967", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4271

Naparima 1972

GEOGCS["Naparima 1972", DATUM["Naparima 1972", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4272

NZGD49

GEOGCS["NZGD49", DATUM["New Zealand Geodetic Datum 1949", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +datum=nzgd49 +no_defs

°

m

4273

NGO 1948

GEOGCS["NGO 1948", DATUM["NGO 1948", ELLIPSOID["Bessel Modified", 6377492.018, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377492.018 +b=6356173.508712696 +towgs84=278.3,93,474.5,7.889,0.05,-6.61,6.21 +no_defs

°

m

4203

AGD84

GEOGCS["AGD84", DATUM["Australian Geodetic Datum 1984", ELLIPSOID["Australian National Spheroid", 6378160, 298.25]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=aust_SA +no_defs

°

m

4204

Ain el Abd

GEOGCS["Ain el Abd", DATUM["Ain el Abd 1970", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4205

Afgooye

GEOGCS["Afgooye", DATUM["Afgooye", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +towgs84=-43,-163,45,0,0,0,0 +no_defs

°

m

4206

Agadez

GEOGCS["Agadez", DATUM["Agadez", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +no_defs

°

m

4207

Lisbon

GEOGCS["Lisbon", DATUM["Lisbon 1937", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4208

Aratu

GEOGCS["Aratu", DATUM["Aratu", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4209

Arc 1950

GEOGCS["Arc 1950", DATUM["Arc 1950", ELLIPSOID["Clarke 1880 (Arc)", 6378249.145, 293.4663077]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.145 +b=6356514.966398753 +no_defs

°

m

4210

Arc 1960

GEOGCS["Arc 1960", DATUM["Arc 1960", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4211

Batavia

GEOGCS["Batavia", DATUM["Batavia", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4212

Barbados 1938

GEOGCS["Barbados 1938", DATUM["Barbados 1938", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=31.95,300.99,419.19,0,0,0,0 +no_defs

°

m

4213

Beduaram

GEOGCS["Beduaram", DATUM["Beduaram", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +towgs84=-106,-87,188,0,0,0,0 +no_defs

°

m

4214

Beijing 1954

GEOGCS["Beijing 1954", DATUM["Beijing 1954", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +no_defs

°

m

4215

Belge 1950

GEOGCS["Belge 1950", DATUM["Reseau National Belge 1950", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4216

Bermuda 1957

GEOGCS["Bermuda 1957", DATUM["Bermuda 1957", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4218

Bogota 1975

GEOGCS["Bogota 1975", DATUM["Bogota 1975", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=307,304,-318,0,0,0,0 +no_defs

°

m

4219

Bukit Rimpah

GEOGCS["Bukit Rimpah", DATUM["Bukit Rimpah", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +towgs84=-384,664,-48,0,0,0,0 +no_defs

°

m

4220

Camacupa

GEOGCS["Camacupa", DATUM["Camacupa", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4221

Campo Inchauspe

GEOGCS["Campo Inchauspe", DATUM["Campo Inchauspe", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4222

Cape

GEOGCS["Cape", DATUM["Cape", ELLIPSOID["Clarke 1880 (Arc)", 6378249.145, 293.4663077]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.145 +b=6356514.966398753 +no_defs

°

m

4223

Carthage

GEOGCS["Carthage", DATUM["Carthage", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +no_defs

°

m

4224

Chua

GEOGCS["Chua", DATUM["Chua", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-134,229,-29,0,0,0,0 +no_defs

°

m

4642

ST84 Ile des Pins

GEOGCS["ST84 Ile des Pins", DATUM["ST84 Ile des Pins", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4643

ST71 Belep

GEOGCS["ST71 Belep", DATUM["ST71 Belep", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-480.26,-438.32,-643.429,16.3119,20.1721,-4.0349,-111.7 +no_defs

°

m

4644

NEA74 Noumea

GEOGCS["NEA74 Noumea", DATUM["NEA74 Noumea", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4646

Grand Comoros

GEOGCS["Grand Comoros", DATUM["Grand Comoros", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4657

Reykjavik 1900

GEOGCS["Reykjavik 1900", DATUM["Reykjavik 1900", ELLIPSOID["Danish 1876", 6377019.27, 300]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377019.27 +b=6355762.5391 +towgs84=-28,199,5,0,0,0,0 +no_defs

°

m

4658

Hjorsey 1955

GEOGCS["Hjorsey 1955", DATUM["Hjorsey 1955", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-73,46,-86,0,0,0,0 +no_defs

°

m

4659

ISN93

GEOGCS["ISN93", DATUM["Islands Network 1993", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4660

Helle 1954

GEOGCS["Helle 1954", DATUM["Helle 1954", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=982.609,552.753,-540.873,32.3934,-153.257,-96.2266,16.805 +no_defs

°

m

4661

LKS92

GEOGCS["LKS92", DATUM["Latvia 1992", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4662

IGN72 Grande Terre

GEOGCS["IGN72 Grande Terre", DATUM["IGN72 Grande Terre", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4663

Porto Santo 1995

GEOGCS["Porto Santo 1995", DATUM["Porto Santo 1995", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4664

Azores Oriental 1995

GEOGCS["Azores Oriental 1995", DATUM["Azores Oriental Islands 1995", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4665

Azores Central 1995

GEOGCS["Azores Central 1995", DATUM["Azores Central Islands 1995", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4666

Lisbon 1890

GEOGCS["Lisbon 1890", DATUM["Lisbon 1890", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4667

IKBD-92

GEOGCS["IKBD-92", DATUM["Iraq-Kuwait Boundary Datum 1992", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4668

ED79

GEOGCS["ED79", DATUM["European Datum 1979", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-86,-98,-119,0,0,0,0 +no_defs

°

m

4669

LKS94

GEOGCS["LKS94", DATUM["Lithuania 1994 (ETRS89)", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4670

IGM95

GEOGCS["IGM95", DATUM["Istituto Geografico Militaire 1995", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4671

Voirol 1879

GEOGCS["Voirol 1879", DATUM["Voirol 1879", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +no_defs

°

m

4672

CI1971

GEOGCS["CI1971", DATUM["Chatham Islands Datum 1971", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=175,-38,113,0,0,0,0 +no_defs

°

m

4158

Naparima 1955

GEOGCS["Naparima 1955", DATUM["Naparima 1955", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4159

ELD79

GEOGCS["ELD79", DATUM["European Libyan Datum 1979", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4160

Chos Malal 1914

GEOGCS["Chos Malal 1914", DATUM["Chos Malal 1914", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4161

Pampa del Castillo

GEOGCS["Pampa del Castillo", DATUM["Pampa del Castillo", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=27.5,14,186.4,0,0,0,0 +no_defs

°

m

4162

Korean 1985

GEOGCS["Korean 1985", DATUM["Korean Datum 1985", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4163

Yemen NGN96

GEOGCS["Yemen NGN96", DATUM["Yemen National Geodetic Network 1996", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4164

South Yemen

GEOGCS["South Yemen", DATUM["South Yemen", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +towgs84=-76,-138,67,0,0,0,0 +no_defs

°

m

4165

Bissau

GEOGCS["Bissau", DATUM["Bissau", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-173,253,27,0,0,0,0 +no_defs

°

m

4166

Korean 1995

GEOGCS["Korean 1995", DATUM["Korean Datum 1995", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4167

NZGD2000

GEOGCS["NZGD2000", DATUM["New Zealand Geodetic Datum 2000", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4168

Accra

GEOGCS["Accra", DATUM["Accra", ELLIPSOID["War Office", 6378300, 296]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378300 +b=6356751.689189189 +towgs84=-199,32,322,0,0,0,0 +no_defs

°

m

4169

American Samoa 1962

GEOGCS["American Samoa 1962", DATUM["American Samoa 1962", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +towgs84=-115,118,426,0,0,0,0 +no_defs

°

m

4170

SIRGAS

GEOGCS["SIRGAS", DATUM["Sistema de Referencia Geocentrico para America del Sur 1995", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4171

RGF93

GEOGCS["RGF93", DATUM["Reseau Geodesique Francais 1993", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4173

IRENET95

GEOGCS["IRENET95", DATUM["IRENET95", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4174

Sierra Leone 1924

GEOGCS["Sierra Leone 1924", DATUM["Sierra Leone Colony 1924", ELLIPSOID["War Office", 6378300, 296]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378300 +b=6356751.689189189 +no_defs

°

m

4175

Sierra Leone 1968

GEOGCS["Sierra Leone 1968", DATUM["Sierra Leone 1968", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-88,4,101,0,0,0,0 +no_defs

°

m

4176

Australian Antarctic

GEOGCS["Australian Antarctic", DATUM["Australian Antarctic Datum 1998", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4178

Pulkovo 1942(83)

GEOGCS["Pulkovo 1942(83)", DATUM["Pulkovo 1942/83", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +towgs84=24,-123,-94,0.02,-0.25,-0.13,1.1 +no_defs

°

m

4179

Pulkovo 1942(58)

GEOGCS["Pulkovo 1942(58)", DATUM["Pulkovo 1942/58", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +no_defs

°

m

4326

WGS 84

GEOGCS["WGS 84", DATUM["World Geodetic System 1984", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

°

m

4600

Anguilla 1957

GEOGCS["Anguilla 1957", DATUM["Anguilla 1957", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4601

Antigua 1943

GEOGCS["Antigua 1943", DATUM["Antigua 1943", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4602

Dominica 1945

GEOGCS["Dominica 1945", DATUM["Dominica 1945", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=725,685,536,0,0,0,0 +no_defs

°

m

4603

Grenada 1953

GEOGCS["Grenada 1953", DATUM["Grenada 1953", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=72,213.7,93,0,0,0,0 +no_defs

°

m

4604

Montserrat 1958

GEOGCS["Montserrat 1958", DATUM["Montserrat 1958", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=174,359,365,0,0,0,0 +no_defs

°

m

4605

St. Kitts 1955

GEOGCS["St. Kitts 1955", DATUM["St. Kitts 1955", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4606

St. Lucia 1955

GEOGCS["St. Lucia 1955", DATUM["St. Lucia 1955", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-149,128,296,0,0,0,0 +no_defs

°

m

4607

St. Vincent 1945

GEOGCS["St. Vincent 1945", DATUM["St. Vincent 1945", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=195.671,332.517,274.607,0,0,0,0 +no_defs

°

m

4608

NAD27(76)

GEOGCS["NAD27(76)", DATUM["North American Datum 1927 (1976)", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4609

NAD27(CGQ77)

GEOGCS["NAD27(CGQ77)", DATUM["North American Datum 1927 (CGQ77)", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4610

Xian 1980

GEOGCS["Xian 1980", DATUM["Xian 1980", ELLIPSOID["Xian 1980", 6378140, 298.257]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378140 +b=6356755.288157528 +no_defs

°

m

4611

Hong Kong 1980

GEOGCS["Hong Kong 1980", DATUM["Hong Kong 1980", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-162.619,-276.959,-161.764,0.067753,-2.24365,-1.15883,-1.09425 +no_defs

°

m

4612

JGD2000

GEOGCS["JGD2000", DATUM["Japanese Geodetic Datum 2000", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4613

Segara

GEOGCS["Segara", DATUM["Gunung Segara", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4614

QND95

GEOGCS["QND95", DATUM["Qatar National Datum 1995", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-119.425,-303.659,-11.0006,1.1643,0.174458,1.09626,3.65706 +no_defs

°

m

4615

Porto Santo

GEOGCS["Porto Santo", DATUM["Porto Santo 1936", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-499,-249,314,0,0,0,0 +no_defs

°

m

4616

Selvagem Grande

GEOGCS["Selvagem Grande", DATUM["Selvagem Grande", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4617

NAD83(CSRS)

GEOGCS["NAD83(CSRS)", DATUM["NAD83 Canadian Spatial Reference System", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +no_defs

°

m

4618

SAD69

GEOGCS["SAD69", DATUM["South American Datum 1969", ELLIPSOID["GRS 1967 (SAD69)", 6378160, 298.25]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=aust_SA +no_defs

°

m

4619

SWEREF99

GEOGCS["SWEREF99", DATUM["SWEREF99", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4620

Point 58

GEOGCS["Point 58", DATUM["Point 58", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=-106,-129,165,0,0,0,0 +no_defs

°

m

4621

Fort Marigot

GEOGCS["Fort Marigot", DATUM["Fort Marigot", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=137,248,-430,0,0,0,0 +no_defs

°

m

4622

Guadeloupe 1948

GEOGCS["Guadeloupe 1948", DATUM["Guadeloupe 1948", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4623

CSG67

GEOGCS["CSG67", DATUM["Centre Spatial Guyanais 1967", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-186,230,110,0,0,0,0 +no_defs

°

m

4624

RGFG95

GEOGCS["RGFG95", DATUM["Reseau Geodesique Francais Guyane 1995", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=2,2,-2,0,0,0,0 +no_defs

°

m

4625

Martinique 1938

GEOGCS["Martinique 1938", DATUM["Martinique 1938", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4626

Reunion 1947

GEOGCS["Reunion 1947", DATUM["Reunion 1947", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4627

RGR92

GEOGCS["RGR92", DATUM["Reseau Geodesique de la Reunion 1992", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4628

Tahiti 52

GEOGCS["Tahiti 52", DATUM["Tahiti 52", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=162,117,154,0,0,0,0 +no_defs

°

m

4629

Tahaa 54

GEOGCS["Tahaa 54", DATUM["Tahaa 54", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4630

IGN72 Nuku Hiva

GEOGCS["IGN72 Nuku Hiva", DATUM["IGN72 Nuku Hiva", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4632

Combani 1950

GEOGCS["Combani 1950", DATUM["Combani 1950", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-382,-59,-262,0,0,0,0 +no_defs

°

m

4633

IGN56 Lifou

GEOGCS["IGN56 Lifou", DATUM["IGN56 Lifou", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4636

Petrels 1972

GEOGCS["Petrels 1972", DATUM["Petrels 1972", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=365,194,166,0,0,0,0 +no_defs

°

m

4637

Perroud 1950

GEOGCS["Perroud 1950", DATUM["Pointe Geologie Perroud 1950", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=325,154,172,0,0,0,0 +no_defs

°

m

4638

Saint Pierre et Miquelon 1950

GEOGCS["Saint Pierre et Miquelon 1950", DATUM["Saint Pierre et Miquelon 1950", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +towgs84=30,430,368,0,0,0,0 +no_defs

°

m

4639

MOP78

GEOGCS["MOP78", DATUM["MOP78", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4640

RRAF 1991

GEOGCS["RRAF 1991", DATUM["Reseau de Reference des Antilles Francaises 1991", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4641

IGN53 Mare

GEOGCS["IGN53 Mare", DATUM["IGN53 Mare", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4714

Bellevue

GEOGCS["Bellevue", DATUM["Bellevue", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-127,-769,472,0,0,0,0 +no_defs

°

m

4715

Camp Area Astro

GEOGCS["Camp Area Astro", DATUM["Camp Area Astro", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-104,-129,239,0,0,0,0 +no_defs

°

m

4716

Phoenix Islands 1966

GEOGCS["Phoenix Islands 1966", DATUM["Phoenix Islands 1966", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=298,-304,-375,0,0,0,0 +no_defs

°

m

4717

Cape Canaveral

GEOGCS["Cape Canaveral", DATUM["Cape Canaveral", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +towgs84=-2,151,181,0,0,0,0 +no_defs

°

m

4718

Solomon 1968

GEOGCS["Solomon 1968", DATUM["Solomon 1968", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4719

Easter Island 1967

GEOGCS["Easter Island 1967", DATUM["Easter Island 1967", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=211,147,111,0,0,0,0 +no_defs

°

m

4720

Fiji 1986

GEOGCS["Fiji 1986", DATUM["Fiji Geodetic Datum 1986", ELLIPSOID["WGS 72", 6378135, 298.26]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS72 +no_defs

°

m

4721

Fiji 1956

GEOGCS["Fiji 1956", DATUM["Fiji 1956", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=265.025,384.929,-194.046,0,0,0,0 +no_defs

°

m

4722

South Georgia 1968

GEOGCS["South Georgia 1968", DATUM["South Georgia 1968", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-794,119,-298,0,0,0,0 +no_defs

°

m

4723

Grand Cayman 1959

GEOGCS["Grand Cayman 1959", DATUM["Grand Cayman 1959", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +towgs84=67.8,106.1,138.8,0,0,0,0 +no_defs

°

m

4724

Diego Garcia 1969

GEOGCS["Diego Garcia 1969", DATUM["Diego Garcia 1969", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=208,-435,-229,0,0,0,0 +no_defs

°

m

4725

Johnston Island 1961

GEOGCS["Johnston Island 1961", DATUM["Johnston Island 1961", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=189,-79,-202,0,0,0,0 +no_defs

°

m

4726

Little Cayman 1961

GEOGCS["Little Cayman 1961", DATUM["Little Cayman 1961", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +no_defs

°

m

4727

Midway 1961

GEOGCS["Midway 1961", DATUM["Midway 1961", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4728

Pico de la Nieves

GEOGCS["Pico de la Nieves", DATUM["Pico de la Nieves", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-307,-92,127,0,0,0,0 +no_defs

°

m

4729

Pitcairn 1967

GEOGCS["Pitcairn 1967", DATUM["Pitcairn 1967", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=185,165,42,0,0,0,0 +no_defs

°

m

4730

Santo 1965

GEOGCS["Santo 1965", DATUM["Santo 1965", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=170,42,84,0,0,0,0 +no_defs

°

m

4732

Marshall Islands 1960

GEOGCS["Marshall Islands 1960", DATUM["Marshall Islands 1960", ELLIPSOID["Hough 1960", 6378270, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378270 +b=6356794.343434343 +towgs84=102,52,-38,0,0,0,0 +no_defs

°

m

4733

Wake Island 1952

GEOGCS["Wake Island 1952", DATUM["Wake Island 1952", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=276,-57,149,0,0,0,0 +no_defs

°

m

4734

Tristan 1968

GEOGCS["Tristan 1968", DATUM["Tristan 1968", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-632,438,-609,0,0,0,0 +no_defs

°

m

4735

Kusaie 1951

GEOGCS["Kusaie 1951", DATUM["Kusaie 1951", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=647,1777,-1124,0,0,0,0 +no_defs

°

m

4736

Deception Island

GEOGCS["Deception Island", DATUM["Deception Island", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=260,12,-147,0,0,0,0 +no_defs

°

m

4737

Korea 2000

GEOGCS["Korea 2000", DATUM["Geocentric datum of Korea", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4738

Hong Kong 1963

GEOGCS["Hong Kong 1963", DATUM["Hong Kong 1963", ELLIPSOID["Clarke 1858", 6378293.64520876, 294.260676369261]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378293.645208759 +b=6356617.987679838 +no_defs

°

Clarke's foot

4739

Hong Kong 1963(67)

GEOGCS["Hong Kong 1963(67)", DATUM["Hong Kong 1963(67)", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-156,-271,-189,0,0,0,0 +no_defs

°

m

4740

PZ-90

GEOGCS["PZ-90", DATUM["Parametrop Zemp 1990", ELLIPSOID["PZ-90", 6378136, 298.257839303]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378136 +b=6356751.361745712 +towgs84=0,0,1.5,-0,-0,0.076,0 +no_defs

°

m

4741

FD54

GEOGCS["FD54", DATUM["Faroe Datum 1954", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4742

GDM2000

GEOGCS["GDM2000", DATUM["Geodetic Datum of Malaysia 2000", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +no_defs

°

m

4743

Karbala 1979 (Polservice)

GEOGCS["Karbala 1979 (Polservice)", DATUM["Karbala 1979 (Polservice)", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +towgs84=84.1,-320.1,218.7,0,0,0,0 +no_defs

°

m

4744

Nahrwan 1934

GEOGCS["Nahrwan 1934", DATUM["Nahrwan 1934", ELLIPSOID["Clarke 1880 (RGS)", 6378249.145, 293.465]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk80 +no_defs

°

m

4745

RD/83

GEOGCS["RD/83", DATUM["Rauenberg Datum/83", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4746

PD/83

GEOGCS["PD/83", DATUM["Potsdam Datum/83", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +no_defs

°

m

4747

GR96

GEOGCS["GR96", DATUM["Greenland 1996", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4748

Vanua Levu 1915

GEOGCS["Vanua Levu 1915", DATUM["Vanua Levu 1915", ELLIPSOID["Clarke 1880 (international foot)", 6378306.3696, 293.46630765563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378306.3696 +b=6356571.996 +towgs84=51,391,-36,0,0,0,0 +no_defs

°

foot

4749

RGNC91-93

GEOGCS["RGNC91-93", DATUM["Reseau Geodesique de Nouvelle Caledonie 91-93", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4750

ST87 Ouvea

GEOGCS["ST87 Ouvea", DATUM["ST87 Ouvea", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=-56.263,16.136,-22.856,0,0,0,0 +no_defs

°

m

4751

Kertau (RSO)

GEOGCS["Kertau (RSO)", DATUM["Kertau (RSO)", ELLIPSOID["Everest 1830 (RSO 1969)", 6377295.664, 300.8017]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377295.664 +b=6356094.667915204 +no_defs

°

m

4752

Viti Levu 1912

GEOGCS["Viti Levu 1912", DATUM["Viti Levu 1912", ELLIPSOID["Clarke 1880 (international foot)", 6378306.3696, 293.46630765563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378306.3696 +b=6356571.996 +towgs84=51,391,-36,0,0,0,0 +no_defs

°

foot

4753

fk89

GEOGCS["fk89", DATUM["fk89", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +no_defs

°

m

4754

LGD2006

GEOGCS["LGD2006", DATUM["Libyan Geodetic Datum 2006", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-208.406,-109.878,-2.5764,0,0,0,0 +no_defs

°

m

4755

DGN95

GEOGCS["DGN95", DATUM["Datum Geodesi Nasional 1995", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4756

VN-2000

GEOGCS["VN-2000", DATUM["Vietnam 2000", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +no_defs

°

m

4757

SVY21

GEOGCS["SVY21", DATUM["SVY21", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +no_defs

°

m

4758

JAD2001

GEOGCS["JAD2001", DATUM["Jamaica 2001", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs

°

m

4801

Bern 1898 (Bern)

GEOGCS["Bern 1898 (Bern)", DATUM["CH1903 (Bern)", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Bern", 7.4395833333], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +pm=bern +no_defs

°

m

4802

Bogota 1975 (Bogota)

GEOGCS["Bogota 1975 (Bogota)", DATUM["Bogota 1975 (Bogota)", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Bogota", -74.0809166667], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +pm=bogota +no_defs

°

m

4803

Lisbon (Lisbon)

GEOGCS["Lisbon (Lisbon)", DATUM["Lisbon 1937 (Lisbon)", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Lisbon", -9.1319061111], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +pm=lisbon +no_defs

°

m

4804

Makassar (Jakarta)

GEOGCS["Makassar (Jakarta)", DATUM["Makassar (Jakarta)", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Jakarta", 106.8077194444], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +towgs84=-587.8,519.75,145.76,0,0,0,0 +pm=jakarta +no_defs

°

m

4805

MGI (Ferro)

GEOGCS["MGI (Ferro)", DATUM["Militar-Geographische Institut (Ferro)", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Ferro", -17.6666666667], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +pm=ferro +no_defs

°

m

4806

Monte Mario (Rome)

GEOGCS["Monte Mario (Rome)", DATUM["Monte Mario (Rome)", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Rome", 12.4523333333], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +pm=rome +no_defs

°

m

4807

NTF (Paris)

GEOGCS["NTF (Paris)", DATUM["Nouvelle Triangulation Francaise (Paris)", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Paris", 2.33722917], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +towgs84=-168,-60,320,0,0,0,0 +pm=paris +no_defs

°

m

4808

Padang (Jakarta)

GEOGCS["Padang (Jakarta)", DATUM["Padang 1884 (Jakarta)", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Jakarta", 106.8077194444], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +pm=jakarta +no_defs

°

m

4809

Belge 1950 (Brussels)

GEOGCS["Belge 1950 (Brussels)", DATUM["Reseau National Belge 1950 (Brussels)", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Brussels", 4.367975], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +pm=brussels +no_defs

°

m

4810

Tananarive (Paris)

GEOGCS["Tananarive (Paris)", DATUM["Tananarive 1925 (Paris)", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Paris", 2.33722917], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-189,-242,-91,0,0,0,0 +pm=paris +no_defs

°

m

4811

Voirol 1875 (Paris)

GEOGCS["Voirol 1875 (Paris)", DATUM["Voirol 1875 (Paris)", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Paris", 2.33722917], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +towgs84=-73,-247,227,0,0,0,0 +pm=paris +no_defs

°

m

4813

Batavia (Jakarta)

GEOGCS["Batavia (Jakarta)", DATUM["Batavia (Jakarta)", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Jakarta", 106.8077194444], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +pm=jakarta +no_defs

°

m

4814

RT38 (Stockholm)

GEOGCS["RT38 (Stockholm)", DATUM["Stockholm 1938 (Stockholm)", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Stockholm", 18.0582777778], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +pm=stockholm +no_defs

°

m

4815

Greek (Athens)

GEOGCS["Greek (Athens)", DATUM["Greek (Athens)", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Athens", 23.7163375], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +pm=athens +no_defs

°

m

4816

Carthage (Paris)

GEOGCS["Carthage (Paris)", DATUM["Carthage (Paris)", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Paris", 2.33722917], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +pm=paris +no_defs

°

m

4817

NGO 1948 (Oslo)

GEOGCS["NGO 1948 (Oslo)", DATUM["NGO 1948 (Oslo)", ELLIPSOID["Bessel Modified", 6377492.018, 299.1528128]], PRIMEM["Oslo", 10.7229166667], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6377492.018 +b=6356173.508712696 +towgs84=278.3,93,474.5,7.889,0.05,-6.61,6.21 +pm=oslo +no_defs

°

m

4818

S-JTSK (Ferro)

GEOGCS["S-JTSK (Ferro)", DATUM["S-JTSK (Ferro)", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Ferro", -17.6666666667], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +pm=ferro +no_defs

°

m

4820

Segara (Jakarta)

GEOGCS["Segara (Jakarta)", DATUM["Gunung Segara (Jakarta)", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Jakarta", 106.8077194444], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +pm=jakarta +no_defs

°

m

4821

Voirol 1879 (Paris)

GEOGCS["Voirol 1879 (Paris)", DATUM["Voirol 1879 (Paris)", ELLIPSOID["Clarke 1880 (IGN)", 6378249.2, 293.466021293627]], PRIMEM["Paris", 2.33722917], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378249.2 +b=6356515 +pm=paris +no_defs

°

m

4895

JAD2001

GEOGCS["JAD2001", DATUM["Jamaica 2001", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4898

DGN95

GEOGCS["DGN95", DATUM["Datum Geodesi Nasional 1995", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4900

LGD2006

GEOGCS["LGD2006", DATUM["Libyan Geodetic Datum 2006", ELLIPSOID["International 1924", 6378388, 297]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=intl +towgs84=-208.4058,-109.8777,-2.5764,0.0,0.0,0.0,0.0 +no_defs

°

m

4901

ATF (Paris)

GEOGCS["ATF (Paris)", DATUM["Ancienne Triangulation Francaise (Paris)", ELLIPSOID["Plessis 1817", 6376523, 308.64]], PRIMEM["Paris", 2.33722917], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6376523 +b=6355862.933255573 +pm=2.3372291666985 +no_defs

°

m

4902

NDG (Paris)

GEOGCS["NDG (Paris)", DATUM["Nord de Guerre (Paris)", ELLIPSOID["Plessis 1817", 6376523, 308.64]], PRIMEM["Paris", 2.33722917], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6376523 +b=6355862.933255573 +pm=paris +no_defs

°

m

4903

Madrid 1870 (Madrid)

GEOGCS["Madrid 1870 (Madrid)", DATUM["Madrid 1870 (Madrid)", ELLIPSOID["Struve 1860", 6378298.3, 294.73]], PRIMEM["Madrid", -3.6879388889], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378298.3 +b=6356657.142669561 +pm=madrid +no_defs

°

m

4904

Lisbon 1890 (Lisbon)

GEOGCS["Lisbon 1890 (Lisbon)", DATUM["Lisbon 1890 (Lisbon)", ELLIPSOID["Bessel 1841", 6377397.155, 299.1528128]], PRIMEM["Lisbon", -9.1319061111], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=bessel +pm=lisbon +no_defs

°

m

4907

RGNC91-93

GEOGCS["RGNC91-93", DATUM["Reseau Geodesique de Nouvelle Caledonie 91-93", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4909

GR96

GEOGCS["GR96", DATUM["Greenland 1996", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4921

GDM2000

GEOGCS["GDM2000", DATUM["Geodetic Datum of Malaysia 2000", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +no_defs

°

m

4923

PZ-90

GEOGCS["PZ-90", DATUM["Parametrop Zemp 1990", ELLIPSOID["PZ-90", 6378136, 298.257839303]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +a=6378136 +b=6356751.361745712 +towgs84=0.0,0.0,1.5,-0.0,0.0,-0.076,0.0 +no_defs

°

m

4925

Mauritania 1999

GEOGCS["Mauritania 1999", DATUM["Mauritania 1999", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4927

Korea 2000

GEOGCS["Korea 2000", DATUM["Geocentric datum of Korea", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4929

POSGAR 94

GEOGCS["POSGAR 94", DATUM["Posiciones Geodesicas Argentinas 1994", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +no_defs

°

m

4931

Australian Antarctic

GEOGCS["Australian Antarctic", DATUM["Australian Antarctic Datum 1998", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4933

CHTRF95

GEOGCS["CHTRF95", DATUM["Swiss Terrestrial Reference Frame 1995", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4935

EST97

GEOGCS["EST97", DATUM["Estonia 1997", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4937

ETRS89

GEOGCS["ETRS89", DATUM["European Terrestrial Reference System 1989", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4939

GDA94

GEOGCS["GDA94", DATUM["Geocentric Datum of Australia 1994", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4941

Hartebeesthoek94

GEOGCS["Hartebeesthoek94", DATUM["Hartebeesthoek94", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4943

IRENET95

GEOGCS["IRENET95", DATUM["IRENET95", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4945

ISN93

GEOGCS["ISN93", DATUM["Islands Network 1993", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4947

JGD2000

GEOGCS["JGD2000", DATUM["Japanese Geodetic Datum 2000", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4949

LKS92

GEOGCS["LKS92", DATUM["Latvia 1992", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4951

LKS94

GEOGCS["LKS94", DATUM["Lithuania 1994 (ETRS89)", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4953

Moznet

GEOGCS["Moznet", DATUM["Moznet (ITRF94)", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0.0,0.0,0.0,-0.0,0.0,0.0,0.0 +no_defs

°

m

4955

NAD83(CSRS)

GEOGCS["NAD83(CSRS)", DATUM["NAD83 Canadian Spatial Reference System", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=-0.991,1.9072,0.5129,0.0257899075194932,-0.009650098960270402,-0.011659943232342112,0.0 +no_defs

°

m

4957

NAD83(HARN)

GEOGCS["NAD83(HARN)", DATUM["NAD83 (High Accuracy Regional Network)", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=-0.991,1.9072,0.5129,0.0257899075194932,-0.009650098960270402,-0.011659943232342112,0.0 +no_defs

°

m

4959

NZGD2000

GEOGCS["NZGD2000", DATUM["New Zealand Geodetic Datum 2000", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4961

POSGAR 98

GEOGCS["POSGAR 98", DATUM["Posiciones Geodesicas Argentinas 1998", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4963

REGVEN

GEOGCS["REGVEN", DATUM["Red Geodesica Venezolana", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4965

RGF93

GEOGCS["RGF93", DATUM["Reseau Geodesique Francais 1993", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4967

RGFG95

GEOGCS["RGFG95", DATUM["Reseau Geodesique Francais Guyane 1995", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=2.0,2.0,-2.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4971

RGR92

GEOGCS["RGR92", DATUM["Reseau Geodesique de la Reunion 1992", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4973

RRAF 1991

GEOGCS["RRAF 1991", DATUM["Reseau de Reference des Antilles Francaises 1991", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4975

SIRGAS

GEOGCS["SIRGAS", DATUM["Sistema de Referencia Geocentrico para America del Sur 1995", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4977

SWEREF99

GEOGCS["SWEREF99", DATUM["SWEREF99", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4979

WGS 84

GEOGCS["WGS 84", DATUM["World Geodetic System 1984", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

°

m

4981

Yemen NGN96

GEOGCS["Yemen NGN96", DATUM["Yemen National Geodetic Network 1996", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4983

IGM95

GEOGCS["IGM95", DATUM["Istituto Geografico Militaire 1995", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS84 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4985

WGS 72

GEOGCS["WGS 72", DATUM["World Geodetic System 1972", ELLIPSOID["WGS 72", 6378135, 298.26]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS72 +towgs84=0.0,0.0,4.5,0.0,0.0,0.554,0.045171992568114105 +no_defs

°

m

4987

WGS 72BE

GEOGCS["WGS 72BE", DATUM["WGS 72 Transit Broadcast Ephemeris", ELLIPSOID["WGS 72", 6378135, 298.26]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=WGS72 +towgs84=0.0,0.0,1.9,0.0,0.0,0.814,-0.07838062637389662 +no_defs

°

m

4989

SIRGAS 2000

GEOGCS["SIRGAS 2000", DATUM["Sistema de Referencia Geocentrico para America del Sur 2000", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4991

Lao 1993

GEOGCS["Lao 1993", DATUM["Lao 1993", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +no_defs

°

m

4993

Lao 1997

GEOGCS["Lao 1997", DATUM["Lao National Datum 1997", ELLIPSOID["Krassowsky 1940", 6378245, 298.3]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=krass +towgs84=44.585,-131.212,-39.544,0.0,0.0,0.0,0.0 +no_defs

°

m

4995

PRS92

GEOGCS["PRS92", DATUM["Philippine Reference System 1992", ELLIPSOID["Clarke 1866", 6378206.4, 294.978698213898]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=clrk66 +towgs84=-127.62,-67.24,-47.04,-3.068,-4.903,-1.578,-0.21864069462192215 +no_defs

°

m

4997

MAGNA-SIRGAS

GEOGCS["MAGNA-SIRGAS", DATUM["Marco Geocentrico Nacional de Referencia", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.0,0.0,0.0,0.0,0.0,0.0,0.0 +no_defs

°

m

4999

RGPF

GEOGCS["RGPF", DATUM["Reseau Geodesique de la Polynesie Francaise", ELLIPSOID["GRS 1980", 6378137, 298.257222101]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]

+proj=longlat +ellps=GRS80 +towgs84=0.072,-0.507,-0.245,-0.0183,-0.0003,0.007,-0.001918262698097996 +no_defs

°

m

Table 1: Supported horizontal geographic coordinate systems


Acronyms

Last edited: 11/8/2017 9:31:50 AM

While we are trying to avoid acronyms wherever possible we still use some acronyms throughout this manual and also within the software. Table 1 describes the used acronyms.

Acronym | Description
DEM | Digital Elevation Model
FFT | Feature / Feature type.
LSO | Location, shape and orientation
PS | Property structure
PSC | Property structure configuration
PSI | Property structure instance
SSF | Spatial support on feature
SSO | Spatial support on observations
WKT | Well known text

Table 1: Acronyms


Used 3rd party products

Last edited: 10/5/2017 11:51:44 AM

Hardly any software product these days can be created without the use of components provided by third parties. Besides some commercial products Redbex makes use of some free/open source/public domain third party component. We say thanks the original authors for their effort!

Table 1 lists the used free/open source 3rd party software together with some licensing information.

Product

Version

Information

nCrontab

2.0.0

Redbex uses this library for interpretation of recurring event schedules

Web: http://code.google.com/p/ncrontab/

License: Apache License, Version 2.0, January 2004, http://www.apache.org/licenses/

NLog

4.2.0

Redbex uses this library for logging on the Application Server and on the Smart Client

Web: http://nlog-project.org/

Licsense: BSD license http://www.opensource.org/licenses/bsd-license.php

Copyright (c) 2004-2011 Jaroslaw Kowalski <jaak@jkowalski.net>

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

·Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

·Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

·Neither the name of Jaroslaw Kowalski nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

LINQKit

Used for building dynamic LINQ statements

Web: http://www.albahari.com

License: permissive free license

Created by Joe Albahari, Ben Albahari and others.

Moq

4.0+

http://code.google.com/p/moq/

Mocking framework. Not used in production code and therfore not deployed, but during testing.

Licsense: BSD license http://www.opensource.org/licenses/bsd-license.php

Copyright (c) 2007. Clarius Consulting, Manas Technology Solutions, InSTEDD

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

·Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

·Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

·Neither the name of Jaroslaw Kowalski nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Command lIne Parser Library

1.9.3.34

Redbex uses this library to parse command line switches

Web: http://commandline.codeplex.com/

License: MIT

Copyright (c) 2005 - 2012 Giacomo Stelluti Scala

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

PROJ.4

4.8

Redbex uses this library for coordinate transformations.

Web: http://trac.osgeo.org/proj/

License: MIT

Copyright (c) 2000, Frank Warmerdam

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Bouncy Castle C# API

1.7

Redbex uses this library for manating cryptographic stuff.

Web: http://www.bouncycastle.org/csharp/index.html

License: Adaptation of MIT

Copyright (c) 2000 - 2011 The Legion Of The Bouncy Castle.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Prism for .NET 4.5

4.5

Prism provides guidance designed to help you more easily design and build rich, flexible, and easily maintained Windows Presentation Foundation (WPF) desktop applications.

Web: http://compositewpf.codeplex.com/

License: Microsoft Patterns & Practices License (http://compositewpf.codeplex.com/license)

Copyright: 2006-2013 Microsoft

SQLite

3.19.3

Used for temporary storage of structured data and for structured storage of logging information.

Web: http://www.sqlite.org/

License: Public domain software

System.Data.SQLite

1.0.105.2

Public domain

License: Microsoft Public License (MS-PL)

dotliquid

1.8.0.0

Used for processing text templates.

Web: http://www.sqlite.org/

License: Apache License, Version 2.0, January 2004, http://www.apache.org/licenses/

SimpleHelpers - FileEncoding

2014

Copyright © 2014 Khalid Salomão

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

License: http://www.opensource.org/licenses/mit-license.php

Website: https://github.com/khalidsalomao/SimpleHelpers.Net

Table 1: Free/open source third party software products used in Redbex

For the user interface and visual experience we used graphics from vendors listed in Table 1

Name | Details
Icons8 Metro Style Icons | Web: http://www.visualpharm.com License: Creative Commons Attribution-NoDerivs 3.0 Unported ( https://creativecommons.org/licenses/by-nd/3.0/ )
Fatcow icons | Web: http://www.fatcow.com/free-icons License: Creative Commons Attribution 3.0 (https://creativecommons.org/licenses/by/3.0/)
Icons from thexamlproject | Web: http://www.thexamlproject.com License: Creative Commons Attribution 3.0 (CC) Credits: ·The Jigsoar icon set by Jigsoar ·Ovestlabs: http://www.ovestlabs.com.au/

Table 2: Graphics used


References

Last edited: 10/5/2017 11:51:34 AM

[1] OpenGIS Implementation Specification: Coordinate Transformation Services, Open Geospatial Consortium, Inc., OpenGIS Project Document 01-009, 2001-01-12.

[2] OpenGIS Simple Features Specification For SQL, Revision 1.1, Open Geospatial Consortium, Inc., OpenGIS Project Document 99-049, 1999-05-05.

[3] Joint Committee for Guides in Metrology (JCGM), International Vocabulary of Metrology, Basic and General Concepts and Associated Terms (VIM), III ed., Pavillon de Breteuil : JCGM 200:2008, 1.1

[4] Ambler Thompson and Barry N. Taylor, Guide for the Use of the International System of Units (SI), NIST Special Publication 811 2008 Edition

[5] ROCK CHARACTERIZATION TESTING MONITORING ISRM Suggested Methods (E.T. Brown) 1981 Pergamon Press Ltd.

[6] Fundamentals and Applications of Rock Mechanics (DEB DEBASIS,VERMA ABHIRAM KUMAR)


Geological mapping in tunnel 001

Last edited: 11/21/2017 6:39:50 AM


Stress reduction factor (SRF)

Last edited: 3/8/2018 7:30:12 AM

SRF Fall | Beskrivning |  |  | SRF
a) Weak zones intersecting the underground opening, which may cause loosening of rock mass.
A | Multiple occurrences of weak zones within a short section containing clay or chemically disintegrated, very loose surrounding rock (any depth), or long sections with incompetent (weak) rock (any depth). For squeezing, see 6L and 6M |  |  | 10.0
B | Multiple shear zones within a short section in competent clay-free rock with loose surrounding rock (any depth) |  |  | 5.0
C | Single weak zones with or without clay or chemical disintegrated rock (depth ≤ 50m). |  |  | 2.5
D | Loose, open joints, heavily jointed or “sugar cube”, etc. (any depth) |  |  | 7.5
E | Single weak zones with or without clay or chemical disintegrated rock (depth > 50m) 2 |  |  | 5.0
F | Enstaka skjuvzoner i kompetent berg (lerfritt) (djup av utbrytning > 50 m). |  |  | 2.5
G | Lösa öppna sprickor, kraftigt uppsprucket berg eller "sockerbitsberg", etc. (alla djup). |  |  | 5.0
b) Kompetent berg, bergspänningsproblem. |  | σc/σ1 | σθ/σc | SRF
H | Låga spänningar, nära ytan, öppna sprickor. | > 200 | < 0.01 | 2.5
J | Medelspänningar, gynnsamma spänningsförhållanden. | 200-10 | 0.01-0.3 | 1.0
K | Höga spänningar, mycket täta strukturer (vanligen gynnsamma för stabilitet, kan vara ogynnsamt för väggstabilitet). | 10-5 | 0.3-0.4 | 0.5-2
L | Måttlig spjälkning efter > 1 tim i massivt berg. | 5-3 | 0.5-0.65 | 5-50
M | Spjälkning och smällberg efter ett par minuter i massivt berg. | 3-2 | 0.65-1.0 | 50-200
N | Kraftigt smällberg och omedelbara deformationer i massivt berg. | < 2 | > 1 | 200-400
c) "Krypning"; berg som uppvisar tidsberoende deformationer eller beteende. |  |  | σθ/σc | SRF
O | Måttligt krypningsbergtryck. |  | 1-5 | 5-10
P | Kraftigt krypningsbergtryck. |  | > 5 | 10-20
d) "Svällning"; kemisk svällning beroende på förekomst av vatten och svällande leror. |  |  |  | SRF
Q | Måttligt svälltryck. |  |  | 5-10
R | Kraftigt svälltryck. |  |  | 10-15
SRF Fall | Beskrivning |  |  | SRF
a) Svaghetszoner som skär utbrytningar och kan orsaka bergutfall när tunneln drivs (bryts ut).
A | Flera (multipla) svaghetszoner som innehåller lera eller kemiskt sönderdelat berg, mycket svagt omgivande berg (alla djup). |  |  | 10.0
B | Enstaka svaghetszoner som innehåller lera eller kemiskt nedbrutet berg (djup av utbrytning < 50 m). |  |  | 5.0
C | Enstaka svaghetszoner som innehåller lera eller kemiskt nedbrutet berg (djup av utbrytning > 50 m). |  |  | 2.5
D | Flera (multipla) skjuvzoner i kompetent berg (lerfritt svagt omgivande berg) (alla djup). |  |  | 7.5
E | Enstaka skjuvzoner i kompetent berg (lerfritt) (djup av utbrytning < 50 m). |  |  | 5.0
F | Enstaka skjuvzoner i kompetent berg (lerfritt) (djup av utbrytning > 50 m). |  |  | 2.5
G | Lösa öppna sprickor, kraftigt uppsprucket berg eller "sockerbitsberg", etc. (alla djup). |  |  | 5.0
b) Kompetent berg, bergspänningsproblem. |  | σc/σ1 | σθ/σc | SRF
H | Låga spänningar, nära ytan, öppna sprickor. | > 200 | < 0.01 | 2.5
J | Medelspänningar, gynnsamma spänningsförhållanden. | 200-10 | 0.01-0.3 | 1.0
K | Höga spänningar, mycket täta strukturer (vanligen gynnsamma för stabilitet, kan vara ogynnsamt för väggstabilitet). | 10-5 | 0.3-0.4 | 0.5-2
L | Måttlig spjälkning efter > 1 tim i massivt berg. | 5-3 | 0.5-0.65 | 5-50
M | Spjälkning och smällberg efter ett par minuter i massivt berg. | 3-2 | 0.65-1.0 | 50-200
N | Kraftigt smällberg och omedelbara deformationer i massivt berg. | < 2 | > 1 | 200-400
c) "Krypning"; berg som uppvisar tidsberoende deformationer eller beteende. |  |  | σθ/σc | SRF
O | Måttligt krypningsbergtryck. |  | 1-5 | 5-10
P | Kraftigt krypningsbergtryck. |  | > 5 | 10-20
d) "Svällning"; kemisk svällning beroende på förekomst av vatten och svällande leror. |  |  |  | SRF
Q | Måttligt svälltryck. |  |  | 5-10
R | Kraftigt svälltryck. |  |  | 10-15

Notera:

Reducera dessa SRF värden med 20-50 % om en skjuvzon av betydelse för tunneln endast påverkar men inte korsar utbrytningen. Detta är också av betydelse för karaktäriseringen.

För kraftig anisotropt spänningsfält (om uppmätt) gäller följande:

i.för 5 £ s1/s 3£ 10, reducera sc till 0.75 sc,
för s1/s3 > 10, reducera sc till 0.5 sc,
där sc är enaxiell tryckhållfasthet, s1 och s3 är största och minsta huvudspänning, och sq är största tangentiella spänningen (uppskattad från elastisk analys).

ii.Det finns få tillgängliga praktikfall där bergtäckningen ner till tunnelns tak är mindre än spännvidden på tunneln. Därför föreslås att SRF ökas från 2.5 till 5 för sådana fall (se H).

iii.Kategori L, M och N är vanligen mest relevanta för förstärkningsdesign för djupt belägna tunnlar i hård, massiv bergmassa, med RQD/Jn-förhållande från omkring 50 till 200.

iv.För generell karaktärisering av bergmassa som inte påverkas av någon utbrytning rekommenderas att använda SRF = 5, 2.5, 1.0 och 0.5 då det vertikala avståndet från marknivå till aktuell bergmassa ökar från t.ex. 0-5, 5-25, 25-250 till > 250 m. Detta hjälper till att anpassa Q-värdet för en del av effekterna av effektivspänningar och vattnets inverkan, i kombination med lämpliga karaktäriseringsvärden på Jw. Sambanden med djupberoende elasticitetsmodul kommer att följa tillämpningen som användes när dessa utvecklades.

v.Fall av krypning kan uppträda för djup H > 350Q1/3. Bergmassans tryckhållfasthet kan uppskattas från scm » 5rQc1/3 [MPa] där r är bergmassans densitet i t/m3, och
Qc = Q×sc/100.


Joint alteration number (Ja)

Navigation: »No topics above this level«

Joint alteration number Ja

Last edited: 3/8/2018 7:30:12 AM

In addition to the joint roughness the joint infill is significant for joint friction. When considering joint infill, two factors are important; thickness and strength. These factors depend on the mineral composition. In the determination of a joint alteration number, the joint infill is divided into three categories (“a”, “b” and “c”) based on thickness and degree of rock wall contact when sheared along the joint plane.

Joint number | Description | Ǿr [°] | Ja
(a) Rock-wall contact (no mineral fillings, only coatings)
A | (a) Rock-wall contact (no mineral fillings, only coatings) | - | 0,75
B | Unaltered joint walls, surface staining only | 25-35 | 1,0
C | Slightly altered joint walls, non-softening mineral coatings, sandy particles, clay-free disintegrated rock, etc. | 25-30 | 2,0
D | Silty- or sandy-clay coatings, small clay fraction (non-softening) | 20-25 | 3,0
E | Softening or low friction clay mineral coatings, i.e., kaolinite or mica. Also chlorite, talc, gypsum, graphite, etc., and small quantities of swelling clays. | 8-16 | 4,0
(b) Rock-wall contact before 10 cm shear (thin mineral fillings).
F | Sandy particles, clay-free disintegrated rock, etc. | 25-30 | 4,0
G | Strongly over-consolidated non-softening clay mineral fillings (continuous, but o5 mm thickness) | 16-24 | 6,0
H | Medium or low over-consolidation, softening, clay mineral fillings (continuous, but o5 mm thickness) | 12-16 | 8,0
J | Swelling-clay fillings, i.e., montmorillonite (continuous, but o5 mm thickness). Value of Ja depends on per cent of swelling clay-size particles, and access to water, etc. | 6-12 | 8-12
(c) No rock-wall contact when sheared (thick mineral fillings).
KLM | Zones or bands of disintegrated or crushed rock and clay (see G, H, J for description of clay condition) | 6-24 | 6, 8 or 8-12
N | Zones or bands of silty- or sandy-clay, small clay fraction (non-softening) | - | 5
OPR | Thick, continuous zones or bands of clay (see G, H, J for description of clay condition) | 6-24 | 10, 13 or 13-20

Fall | Beskrivning | Ǿr [°] | Ja
a) Bergkontakt vid skjuvning (inga fyllnadsmineral, endast ytbeläggning).
A | Tät, läkt, hård, ej deformationsmjuknande, impermeabel fyllning, dvs. kvarts eller epidot. | - | 0,75
B | Opåverkade (ej omvandlade) sprickytor, endast missfärgning av sprickytan (beläggning). | 25-35 | 1,0
C | Svagt omvandlade sprickytor. Ej deformationsmjuknande mineralbeläggning, sandiga partiklar, lerfritt krossat berg, etc | 25-30 | 2,0
D | Siltig eller sandig lerbeläggning, låg lerfraktion (ej deformationsmjuknande). | 20-25 | 3,0
E | Deformationsmjuknande eller lågfriktionsbeläggning av lermineral, dvs. kaolin och glimmer. Även klorit, talk, gips, och grafit, m.m., och små kvantiteter av svällande lera. | 8-16 | 4,0
b) Bergkontakt uppnås före 10 cm skjuvdeformation (tunn mineralfyllning).
F | Sandiga partiklar, lerfritt sönderdelat berg, etc. | 25-30 | 4,0
G | Kraftigt överkonsoliderad, ej deformationsmjuknande lermineralfyllning (kontinuerlig, < 5 mm tjocklek). | 16-24 | 6,0
H | Medel- eller lågt överkonsoliderad, deformationsmjuknande, lermineralfyllning (kontinuerlig, < 5 mm tjocklek). | 12-16 | 8,0
J | Fyllning av svällande lera, dvs. montmorillonit (kontinuerlig, <5 mm tjocklek). Värdet av Ja beror på andel (%) av svällande lerpartiklar och tillgång till vatten, etc. | 6-12 | 8-12
c) Ingen bergkontakt uppnås vid skjuvning (tjock mineralfyllning).
KLM | Zoner eller band av krossat eller sönderdelat berg och lera (se G, H, J för beskrivning för lerförhållanden). | 6-24 | 6, 8 eller 8-12
N | Zoner eller band av siltig eller sandig lera (ej deformationsmjuknande). | - | 5
OPR | Tjocka, kontinuerliga zoner eller band av lera (se G, H, J för beskrivning för lerförhållanden) | 6-24 | 10, 13 eller 13-20


Joint set number (Jn)

Navigation: »No topics above this level«

Joint set number Jn

Last edited: 3/8/2018 7:30:12 AM

Shape and size of the blocks in a rock mass depend on the joint geometry. Joints within a joint set will be nearly parallel to one another and will display a characteristic joint spacing. Joints that do not occur systematically or that have a spacing of several meters are called random joints. However, the effect of spacing strongly depends on the span or height of the underground opening. If more than one joint belonging to a joint set appears in the underground opening, it has an effect on the stability and should be regarded as a joint set. The number of Jn is not the same as the number of joint sets.

Number | Description | Jn
A | Massive, no or few joints | 0.5 – 1.0
B | One joint set | 2
C | One set plus random joints | 3
D | Two joint sets | 4
E | Two join sets plus random joints | 6
F | Three joint sets | 9
G | Three joint sets plus random joints | 12
H | Four or more joint sets, random, heavily jointed, ‘sugar-cube’, etc.. | 15
J | Crushed rock, earthlike | 20

Notes:
i. For tunnel intersections, use (3:0 Jn).
ii. For portals use (2:0Jn).

Sprickgruppstal, Jn | Beskrivning | Jn
A | Massivt berg, inga eller få sprickor. | 0,5 – 1,0
B | En sprickgrupp. | 2
C | En sprickgrupp samt slumpvisa sprickor. | 3
D | Två sprickgrupper. | 4
E | Två sprickgrupper samt slumpvisa sprickor. | 6
F | Tre sprickgrupper. | 9
G | Tre sprickgrupper samt slumpvisa sprickor. | 12
H | Fyra sprickgrupper eller fler, slumpvisa sprickor, kraftigt uppsprucket berg, "sockerbitsberg", etc. | 15
J | Krossat berg, jordaktigt berg. | 20

Notera:

i.Vid tunnelkorsning använd (3.0·Jn).

ii.För påslag (tunnelmynning) använd (2.0·Jn).


%Text%

Navigation: »No topics above this level«

Archive

Last edited: 10/25/2017 6:37:04 AM

This chapter includes change logs to old releases of Redbex


Action log

Last edited: 11/8/2017 10:15:02 AM

In many cases the Application Server logs details about the processing of some request to so called action logs.

An action log contains structured information that is intended for the human reader. The action log can be sent back to clients as part of the result of a request. An action log consists of action log entries. Table 1 describes the information contained in an action log entry. Figure 1 shows an example of an action log.

Item | Description
Entry No | Sequential number of the entry
Timestamp | The timestamp when this entry was created
Entry text | The textual information. This textual information is always in English.
Level | The action log can form hierarchies of entries. The level describes the hierarchy level of a specific entry.

Table 1: Information contained within an action log entry

Figure 1: Example of an action log. This action log was sent to the client as a response to the login.


Approval status colors

Last edited: 12/13/2017 7:51:04 AM

Color | Description
 | In Progress
 | Ready
 | In Approval
 | Approved
 | Approval denied
 | Approved but erroneous
 | Approval aborted
 | Approval exired


Versioning

Last edited: 11/8/2017 10:15:02 AM

Over time the Application Server will be deployed in different versions, new features might be added, bugs removed etc. To distinguish between different versions of the Application Server each version has a unique version number. Version numbers consist of four components: major, minor, build, and revision. All components are integers greater than or equal to 0. The format of the version number is as follows:

<major version>.<minor version>.<build number>.<revision>

The components are used by convention as follows:

·Major: Application Servers with different major versions are not interchangeable. A higher version number indicates a major rewrite of a product or great enhancements in functionality, where backward compatibility cannot be assumed. If the major version number changes a new license is necessary. A change in the major version number indicates a change in the Web Services API, therefore the client (e.g. the Smart Client) software has to be updated to be compatible with the new Application Server version.

·Minor: If the major version number on two Application Server versions are the same, but the minor version number is different, this indicates significant enhancements. A change in the minor version number indicates a change in the Web Services API, therefore the client (e.g. the Smart Client) software has to be updated to be compatible with the new Application Server version.

·Build: A difference in build number indicates a new version with no significant new features implemented, but a few small improvements and bug fixes. If the Application Server's build number changes clients (e.g. the Smart Client) do not have to be updated.

·Revision: A difference in revision number indicates a new version with small changes e.g. bug fixes. If the Application Server's revision number changes clients (e.g. the Smart Client) do not have to be updated.

Checking the Application Server Database version

When the Redbex Application Server starts up and connects to the Application Server Database it will read out the version of the Application Server Database and decide if the current Application Server supports that database version. This is done by comparing the major and minor component of the database version number to a compatibility version number that is hard coded within the Application Server. In other words all versions of the Application Server database that have a major and minor version number that equals the major and minor compatibility version number hard coded within the Application Server are compatible with that version of the Application Server.

Example: If the Database Version number is 3.4.5.2 and the hard coded compatibility version number in is 3.4.0.0 the Application Server can use that database. If the compatibility version number would be 3.5.0.0 or 2.1.0.0 the Application Server cannot use that database.

The database compatibility version number is logged on application server startup and is also reported by the server information service.


Axis Position

Last edited: 10/5/2017 11:51:04 AM

Represents a changing position on a tunnel axis, e.g. for advance status.

Characteristic | Note
Name | Axis position
Path | \Tunneling
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on observation
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for extended observation


Axis section drawing

Last edited: 10/5/2017 11:51:04 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Global settings

Last edited: 10/25/2017 6:37:04 AM

Axis section drawing settings is a UConfiguration that includes settings which affect the section drawing as a whole. These settings do not influence what is drawn but just how things are drawn. Tables 1 and 2 list the available settings.

General settings

Setting

Description

Scaling factor

The factor that is used to map real-world axis reference system offsets to millimeters. See below for more details

Default: 1.0

Validation: > 0.1 and ≤ 10 000

See below for examples for this setting.

Title

A text template used as used to define a title that will be shown on top of the drawing.

The text template may includes specific variables to express properties of the used axis reference system and the underlying axis.

Subtitle 1

A text template used as used to define the first subtitle that will be shown beneath the title. This string is a text template.

The text template may includes specific variables to express properties of the used axis reference system and the underlying axis.

Subtitle 2

A text template used as used to define second subtitle that will be shown beneath the title. This string is a text template.

The text template may includes specific variables to express properties of the used axis reference system and the underlying axis.

Footer

A text template used to define a footer line that will be shown beneath the drawing. This string is a text template.

The text template may includes specific variables to express properties of the used axis reference system and the underlying axis.

Drawing header height

Height of the drawing header in mm.

Title font size

Size of the font used for the title. Given in millimeters.

Default: 10

Validation: > 0.1 and ≤ 100

Subtitle font size

Size of the font used for subtitle 1 and subtitle 2. Given in millimeters.

Default: 6

Validation: > 0.1 and ≤ 100

Header / footer font size

Size of the font used for header and footer text. Given in millimeters.

Default: 3

Validation: > 0.1 and ≤ 100

Header / footer color

Defines the color for the text shown in the drawing header and footer.

Default: Black

Row header width

Width of the row header in millimeter. You can hide the row header by setting this to zero.

Default: 40

Validation: ≥ 0.0

Legend width

Width of the row legend in millimeter. You can hide the row legend by setting this to zero.

Default: 30

Validation: ≥ 0.0

Row title font size

Defines the size in millimeters of the font used for showing row headers.

Default: 2.5mm

Validation: ≥ 0.1

Row subtitle font size

Defines the size in millimeters of the font used for showing row sub- headers.

Default: 2mm

Validation: ≥ 0.1

Row border stroke color

Defines the color used to draw of the row borders

Default: Dark grey

Row border stroke width

The width in millimeters of the row row border strokes.

Default: 0.5

Validation: > 0.1 and ≤ 1.0

Table 1: General Axis section drawing settings

Scaling factor examples

The scaling factor defines how 'real world' units i.e. the linear units used with the axis reference system are mapped to millimeters. The millimeters used to represent a distance given in the used axis reference system is calculated by multiplying the given distance with the scaling factor. Table 3 shows some examples.

Real world value | Scaling factor | Size on drawing
1 meter | 1 | 1 mm
100 meters | 0.1 | 10 mm
100 meters | 0.5 | 50
1 mile | 304.8 | 304.8 mm (=1 foot)
1 mile | 25.4 | 25.4 mm (=1 inch)

Table 2: Examples of scaling factors

Vertical grid settings

The vertical grid settings define the display of vertical grid lines and ticks. While the definition of this vertical grid is global it can be overridden on a per-row basis.

Setting

Description

Color

Sets the default color of the graphical elements that are used for the vertical grid. This setting can be overridden in every row.

Default: Light grey

Major ticks distance

Defines the default distance between two consecutive major ticks; given in the linear unit of the used axis reference system. This setting can be overridden in every row.

Default: 10

Validation: > 0.0

Minor ticks between major ticks

Defines how many minor ticks shall be shown between two major ticks. If set to zero no minor ticks will be shown. This setting can be overridden in every row.

Default: 9

Validation: ≥ 0

Grid style

Defines the style of the grid display. Following options are available

·Style 1: Major ticks are lines from top of row to bottom, minor ticks are short lines starting at the row bottom

·Style 2: Major ticks are lines from top of row to bottom, minor ticks are short lines starting at the row bottom and a mirrored short line starting from the row top

Grid Z-Order

Specifies if the grid lines are drawn in front of other drawing elements or in the back of other drawing elements.

Table 3: Axis section drawing settings for the vertical grid

Other settings

Setting | Description
Status date | When displaying the location of feature with spatial support on observations the location of the feature will be set according to the location stored with the observation nearest to the given date and time value. If null the latest observation's spatial data will be used. Default: null

Table 3: Axis section drawing settings in the Other settings group


Joitn water reduction facor (Jw)

Last edited: 3/8/2018 7:30:14 AM

Factor | Beskrivning | Approx. water pres. (kg/cm2 ) | Jw
A | Dry excavations or minor inflow, i.e., o5 l/min locally | < 1 | 1.0
B | Medium inflow or pressure, occasional outwash of joint fillings | 1-2.5 | 0.66
C | Large inflow or high pressure in competent rock with unfilled joints | 2.5-10 | 0.5
D | Large inflow or high pressure, considerable outwash of joint fillings | 2.5-10 | 0.33
E | Exceptionally high inflow or water pressure at blasting, decaying with time | > 10 | 0.2-0.1
F | Exceptionally high inflow or water pressure continuing without noticeable decay | > 10 | 0.1-0.05

(i) Factors C to F are crude estimates. Increase Jw if drainage measures are installed.

(ii) Special problems caused by ice formation are not considered.

(iii) For general characterisation of rock masses distant from excavation influences, the use of Jw ¼ 1:0; 0.66, 0.5, 0.33, etc. as depth increases from say 0–5, 5–25, 25–250 to >250 m is recommended, assuming that RQD=Jn is low enough (e.g. 0.5–25) for good hydraulic connectivity. This will help to adjust Q for some of the effective stress and water softening effects, in combination with appropriate characterisation values of SRF. Correlations with depth-dependent static deformation modulus and seismic velocity will then follow the practice used when these were developed.

Sprickvattental | Beskrivning | Approx. vattentryck (kg/cm2) | Jw
A | Torr utbrytning (bergrum, tunnel) eller mindre inflöde, dvs. 5 liter/min lokalt. | < 1 | 1,0
B | Medelstort inflöde eller tryck, enstaka ursköljningar av sprickfyllnadsmaterial. | 1-2,5 | 0,66
C | Stora inflöden eller högt tryck i kompetent berg med ofyllda sprickor. | 2,5-10 | 0,5
D | Stora inflöden eller högt tryck, ursköljningar av sprickfyllnadsmaterial. | 2,5-10 | 0,33
E | Exceptionellt stora inflöden eller högt tryck vid sprängning, minskande flöde med tid. | > 10 | 0,2-0,1
F | Exceptionellt stora inflöden eller högt tryck, kontinuerligt flöde utan noterbar minskning med tid. | > 10 | 0,1-0,05

i.Faktorerna C till F är grova uppskattningar. Öka Jw om dräneringsåtgärder är installerade.

ii.Speciella problem orsakade av isbildning är inte beaktade.

iii.För generell karaktärisering av bergmassa som inte påverkas av någon utbrytning rekommenderas att använda Jw = 1.0, 0.66, 0.5, 0.33 då det vertikala avståndet från marknivå till aktuell bergmassa ökar från 0-5, 5-25, 25-250 till > 250 meter. Detta gäller under förutsättning att förhållandet RQD/Jn är tillräckligt lågt (dvs. 0.5–25) för att god hydraulisk konduktivitet skall råda i bergmassan. Detta hjälper till att anpassa Q-värdet för en del av effekterna av effektivspänningar och vattnets inverkan, i kombination med lämpliga karaktäriseringsvärden på SRF. Sambanden med djupberoende elasticitetsmodul kommer att följa tillämpningen som användes när dessa utvecklades.


Joint roughness number (Jr)

Navigation: »No topics above this level«

Joint roughness number Jr

Last edited: 3/8/2018 7:30:14 AM

 | Description | Jr
(a) Rock-wall contact, and (b) rock-wall contact before 10 cm sear
A | Discontinuous joints | 4
B | Rough or irregular, undulating | 3
C | Smooth, undulating | 2
D | Slickensided, undulating | 1.5
E | Rough or irregular, planar | 1.5
F | Smooth, planar | 1.0
G | Slickensided, planar | 0.5
(c) No rock-wall contact when sheared
H | Zone containing clay minerals thick enough to prevent rock-wall contact. | 1.0
J | Sandy, gravely or crushed zone thick enough to prevent rock-wall contact | 1.0

Notes:

i Descriptions refer to small-scale features and intermediate scale features, in that order.

ii Add 1.0 if the mean spacing of the relevant joint set is greater than 3 m.

iii Jr ¼ 0:5 can be used for planar, slickensided joints having lineations, provided the lineations are oriented for minimum strength. (iv) Jr and Ja classification is applied to the joint set or discontinuity that is least favourable for stability both from the point of view of orientation and shear resistance, t(where tEsn tan?1 (Jr=Ja).

Sprickråhetstal, Jr | Beskrivning | Jr
a) Bergkontakt vid skjuvning, samt b) bergkontakt uppnås före 10 cm skjuvdeformation.
A | Diskontinuerliga sprickor. | 4
B | Råa eller ojämna, vågformiga (böljande) sprickor. | 3
C | Släta, vågformiga (böljande) sprickor. | 2.0
D | Glatta (blankslag), vågformiga (böljande) sprickor. | 1.5
E | Råa eller ojämna, plana sprickor. | 1.5
F | Släta, plana sprickor. | 1.0
G | Glatta (blankslag), plana sprickor. | 0.5
c) Ingen bergkontakt uppnås vid skjuvdeformation.
H | Lermineralhaltiga zoner, med tillräcklig tjocklek för att förhindra bergkontakt. | 1.0
J | Zon med sandigt, grusigt eller krossat bergmaterial med tillräcklig tjocklek för att förhindra bergkontakt. | 1.0

Notera:

i.Beskrivningen syftar på, i följande ordning, småskaliga egenskaper och mellanskaliga egenskaper.

ii.Lägg till 1.0 om medelsprickavståndet av betydande sprickgrupper är större än 3 m.

iii.Jr = 0.5 kan användas för plana, glatta sprickor som har stänglighet, förutsatt att stänglighetens orientering ger minsta möjliga hållfasthet.

iv.Val av värde för Jr och Ja görs för den sprickgrupp eller diskontinuitet som är minst gynnsam för stabiliteten med avseende på både orientering och skjuvmotstånd,τ [där τ ≈ σn tan-1 (Jr/Ja)].


Changing the installation scenario

Last edited: 10/25/2017 6:37:04 AM

It is possible to change the installation scenario after installation without loosing configuration settings. Following chapters describe how you can move


Charting

Last edited: 10/5/2017 11:51:08 AM

Redbex provides a set of generic charts that can depict numeric data in different ways.


Configurations for sets of features

Last edited: 11/8/2017 10:15:02 AM

There are several functionalities in Redbex that you usually want to configure for a set of features rather than for each feature separately. In Redbex there are two different concepts that are used to accomplish this: Feature Directives and Feature Configurations.

If a functionality is configured as a feature directive, different configurations of this functionality can apply to one feature at the same time. E.g. multiple observation plans can be configured for the same feature at the same time.

If a functionality is configured as a Feature Configuration only one configuration can exist for one feature at a feature. E.g. there can be only one default value for a property of an observation.

Feature directives
Observation monitoring | Observation monitoring definitions
Observation plans | Definition of observation plans, and reminders
Approval Workflow assignments | Assigns approval workflow templates to features
Feature Configurations
Graphical appearance of features | Defines the graphical appearance of features.
Report template assignments | Dynamically assigns Report templates to features
Feature property structure configuration | Default Values for properties Naming of properties Sequence of property display Grouping of properties Visual appearance of properties Default values for properties Validation rules for properties and collections
Observation Property structure configuration | Default Values for properties Naming of properties Sequence of property display Grouping of properties Visual appearance of properties Default values for properties Validation rules for properties and collections

Table 1: Summary of functionalities configured with feature directives or feature configurations


Context evaluation

Last edited: 10/5/2017 11:51:12 AM

Depending on the type of setting that is associated with the context, the system uses two different approaches to determine the applicable settings for a specific sensor: the first match or all matches approach.

The first match approach is used whenever only one setting is needed. E.g. the default value of a property in a property structure can be only one value, there might be different default value settings with sensor setting contexts that match a specific sensor still only one of these settings can be used.

The first match in the first match approach is determined by sorting all settings with matching contexts by their sensor setting context specificity. Table 1 lists the contexts from highest specificity to lowest specificity. The first match is the match with the highest specificity.

The all matches approach is used whenever all of the settings that match the context of the sensor can be used. E.g. there can be any number of validation rules for a property in a property structure. When validating a property all validation rules whose context match the current sensor's context will be checked.

Context

Sensor

Domain + sensor type

Table 1: Sensor contexts ordered by their specificity, highest specificity first


Context types

Last edited: 10/5/2017 11:51:12 AM

Table 1 list all sensor contexts supported by the Application Server. Note that each context always implies a sensor type i.e. regardless of which context is chosen the setting will always apply only to sensors of one specific sensor type, i.e. feature settings are always feature type specific. A setting with a context that includes a domain will match for all member sensors i.e. all sensors assigned to that domain or any of its sub domains.

Context | Matches
Sensor | Explicit context. Only for that specific sensor. Note that the sensor type is of course implicitly defined by the sensor.
Domain + sensor type | Implicit context. Matches all sensors of the specified sensor type that are member of the specified domain

Table 1: Sensor setting contexts


Creating local users

Last edited: 10/25/2017 6:37:06 AM

lusrmgr.msc


Domain privileges & permissions

Last edited: 11/8/2017 10:15:02 AM

Permissions for domains control access to the domains and many indirect permission objects linked to domains e.g. axes, or cross sections.

Domain privileges granting the domain permission Read (0) are propagated up and down the domain tree. I.e. if the Read (0) is granted to a domain the privilege will also apply to all of the domains on the path of this domain. The Read (0) permission is always granted to all users on the root domain, however that specific permission is not propagated down the tree.

Domain privileges granting any other domain permission than Read (0) are propagated down the domain tree. I.e. if the privilege is granted to a domain the privilege will be inherited by all subordinate domains.

Read permissions of features that are member of a domain are transformed to a read permission on the domain itself, therefore whenever a read permission is given on a feature (either directly or transformed from a view permission) this will automatically imply read permission on the domain

Table 1 lists the permissions that can be granted for domains and effect the domains themselves, table 2 lists indirect permissions that are granted on domain as privilege objects but define the access rights on indirect privilege objects linked to the domains.

Permission

No

Description, Actual actions granted

Read (0)

0

Read all data of the domain, including

·Sensors

·Classifications

·Axes and axis reference systems

·Presentation templates

·Alias schemes

·Approval templates

·...

and all other data liked to a domain. Does not include the right to read all features linked to that domain.

Note that read permission on a domain is implicitly granted to a user if that user has read permission on one of the features belonging to that domain.

Modify (2)

2

Modify data of the domain. Includes the permission to:

·delete domains (except root domain which cannot be deleted).

·create subordinate domains.

·set privilege propagation break

·hide feature types

Note that deleting of domains is only possible if no other data is linked to that domain.

Modify privileges (3)

3

If granted the privilege subject can modify the privileges on that domain. However the privilege subject can only add or remove privileges that it is granted itself.

Table 1: Permissions on domains

The permission to read data linked to a domains (except features) is either granted directly by granting the Read permission or indirectly by the system If a user has the permission to read a feature or some other content that is assigned to a specific domain the system will implicitly grant the right to read all other content except features in the same domain or a parent domain thereof.

Permission | No | Description
Hide feature types (6) | 6 | Hide specific feature types in this domain. Will restrict the feature types that are available when creating new features in that domain.
Manage alias schemes (7) | 7 | Create modify and delete alias schemes. This permission does not implicitly allow to translate features names in a scheme - alias names for a feature can only be modified if the user has modify permission on the feature.
Manage axes (10) | 10 | If granted axes and axis reference systems can be created and modified in the domain.
Manage presentation templates (9) | 9 | If granted presentation templates can be created and modified in this domain
Observation monitoring (8) | 8 | If granted you can create monitoring definitions on a feature type in that domain given that you also have the Modify feature settings (4) on that feature type.
Permission | No | Description

Table 2: Permissions on on domains that effect indirect privilege objects

Permission

No

Description

Create features (4)

4

Permission to create features that are member of this domain. To actually be allowed to create a feature the feature type permission Create features of this type has to be granted also.

Note if there is no view containing the newly created feature that assigns permissions to the creating user, the user might be able to create a feature but can not read or modify it

Modify approval templates (11)

11

Permission to create, modify and delete approval templates that are member of a specific domain.

To be allowed to actually create, modify or delete an approval template the user also needs modify approval templates permission on the feature type the approval template references.

Modify Classifications (13)

13

Permission to create modify and delete classifications that are member of a specific domain.

To be allowed to actually create, modify or delete a classification the user also needs modify classifications permission on a feature type that uses classifications of that classification type.

Modify feature settings (15)

15

Modify feature settings where the context is a feature setting with a context that reference a specific domain.

To be allowed to actually create, modify or delete a feature setting the user also needs modify feature settings permission on feature type the setting context references.

Modify feature subtypes (14)

14

Propagation direction: down

Permission to create modify and delete feature subtypes within that domain.

To be allowed to actually create, modify or delete a feature subtype the user also needs modify feature subtypes permission on the feature type the subtype belongs to.

Modify sensors (12)

12

Permission to create, modify and delete sensors that is member of a specific domain.

To be allowed to actually create, modify or delete a sensor the user also needs modify sensors permission on the feature type the sensor belongs to (via its sensor type).

Modify sensor settings (16)

16

Modify feature settings where the context is a sensor setting with a context that reference a specific domain.

To be allowed to actually create, modify or delete a feature setting the user also needs modify sensor settings permission on feature type the setting context references (via the sensor type reference in the context).

Set used classification (5)

5

If granted the classification that is used for a specific classification type in this domain can be defined.

To be allowed to actually set the used classification for a specific classification type, the user also needs modify feature settings permission on one of the the feature types classification type belongs to.

Manage cross sections (17)

17

Permission to create, modify and delete cross sections that are member of a specific domain.

Manage feature creation templates (18)

18

Permission to create, modify and delete Feature Creation Templates that are member of a specific domain.

Manage Map file sets (19)

19

Permission to create, modify and delete Map File Sets that are member of a specific domain.

Manage import definitions (20)

20

Permission to create, modify and delete Stored Import Definitions that are member of a specific domain.

Manage export definitions (21)

21

Permission to create, modify and delete Stored Export Definitions that are member of a specific domain.

Table 3; Permissions on on domains that effect indirect privilege objects. For the permissions listed here to take effect the appropriate feature type permission has to be granted also.


Versioning

Last edited: 11/8/2017 10:15:02 AM

Over time the Application Server Database will be deployed in different versions. The database structure including tables, relations, stored procedures etc will differ between different versions.

To distinguish between different versions of the Application Server Databases each version has a unique version number. Version numbers consist of two components: major and minor. All components are be integers greater than or equal to 0. The format of the version number is as follows:

<major version>.<minor version>.<build number>.<revision>

The components are used by convention as follows:

·Major: Application Server Databases with different major versions are not interchangeable. A higher version number indicates a major structure change in the databases where backward compatibility cannot be assumed.

·Minor: If the major version number on two Application Server Database versions are the same, but the minor version number is different, this indicates significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of the product or a fully backward-compatible new version of the product.

·Build: A difference in build number indicates a new version with no significant new features implemented, however a few small improvements may be included. A change in the build number does not break compatibility with an already installed Application Server.

·Revision: A difference in revision number indicates a new version with small changes e.g. bug fixes. A change in the build number does not break compatibility with an already installed Application Server.

Whenever the Application Server starts up it will check the Version of the database, see Application Server versioning for details.


2015-10-16T10:19:42.4513478+02:00	10	FC	33646	{"DataDomainId":1,"FeatureTypeId":45,"Name":"LogTestExt3","ParentPlatformFeatureId":null,"DefaultSensorId":null,"FeatureSubTypeId":null,"DataSource":0,"ConnectorType":null,"CoordinateSystemId":null,"AxisReferenceSystemId":null,"SpatialDataLso":null,"PropertyStructure":{"Id":0,"DefinitionPropertyStructureId":135,"Properties":[{"Id":0,"PropertyDefinitionId":345,"Value":0,"PropertyType":4},{"Id":0,"PropertyDefinitionId":346,"Value":0,"PropertyType":4},{"Id":0,"PropertyDefinitionId":347,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":348,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":349,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":350,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":351,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":352,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":353,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":354,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":355,"Value":null,"PropertyType":3}],"Collections":[],"LastModificationDate":"2015-10-16T08:19:42.3038214Z","CollectionPosition":0},"UseRelativeParentLocation":false}


2015-10-16T10:20:25.6421227+02:00	10	FM	33646	{"Id":33646,"NewName":"LogTestExt3ChangeName","NewDescription":"NewDesc","NewFeatureSubTypeId":null,"PropertyStructure":null,"SpatialDataLso":null,"UseContainerLSO":false,"ContainerLsoOffsetA":null,"ContainerLsoOffsetB":null,"ContainerLsoOffsetC":null,"DefaultSensorId":null}


Sample: 2015-10-16T10:24:19.7962695+02:00	10	OC	33646	2437797	{"Observation":{"Id":0,"ClientId":"16b28490-eb89-448c-b515-76fb22863371","FeatureId":33646,"SensorId":null,"SamplingTimestamp":"2015-10-16T08:24:05.5299797Z","ResultTimestamp":null,"AxisLocation":0,"IsErroneous":false,"IsDeleted":false,"SpatialData":null,"SpatialDataSupport":0,"ReferenceSystem":null,"ApprovalStatus":0},"PropertyStructure":{"Id":0,"DefinitionPropertyStructureId":136,"Properties":[{"Id":0,"PropertyDefinitionId":356,"Value":5,"PropertyType":4},{"Id":0,"PropertyDefinitionId":357,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":358,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":359,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":360,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":361,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":362,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":363,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":364,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":365,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":366,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":367,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":368,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":369,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":370,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":371,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":372,"Value":false,"PropertyType":5}],"Collections":[],"LastModificationDate":null,"CollectionPosition":0}}


var dippingPropertyId = featurePropertyStructureDefinition.GetPropertyId(GroundWaterLevelConstants.Dip);
        var aquiferTypePropertyId = featurePropertyStructureDefinition.GetPropertyId(GroundWaterLevelConstants.AquiferType);
        var drillHoleTypePropertyId = featurePropertyStructureDefinition.GetPropertyId(GroundWaterLevelConstants.DrillHoleType);
        var elevationOfTopEdgePropertyId = featurePropertyStructureDefinition.GetPropertyId(GroundWaterLevelConstants.ElevationOfTopEdge);
        var filterLengthPropertyId = featurePropertyStructureDefinition.GetPropertyId(GroundWaterLevelConstants.FilterLength);
        var elevationOfEndPropertyId = featurePropertyStructureDefinition.GetPropertyId(GroundWaterLevelConstants.ElevationOfEnd);
        var waterLevelPropertyId = featurePropertyStructureDefinition.GetPropertyId(GroundWaterLevelConstants.WaterLevel);
        var standardCommentPropertyId = featurePropertyStructureDefinition.GetPropertyId(GroundWaterLevelConstants.StandardComment);


2015-10-16T10:24:25.4540391+02:00	10	OM	33646	2437798	{"Id":2437798,"SamplingTimestamp":"2015-10-17T08:24:00Z","ResultTimestamp":null,"PropertyStructure":{"Id":2683249,"DefinitionPropertyStructureId":136,"Properties":[{"Id":0,"PropertyDefinitionId":372,"Value":false,"PropertyType":5},{"Id":0,"PropertyDefinitionId":356,"Value":10,"PropertyType":4},{"Id":0,"PropertyDefinitionId":357,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":358,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":359,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":360,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":361,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":362,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":363,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":364,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":365,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":366,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":367,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":368,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":369,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":370,"Value":null,"PropertyType":4},{"Id":0,"PropertyDefinitionId":371,"Value":null,"PropertyType":4}],"Collections":[],"LastModificationDate":null,"CollectionPosition":0},"IsErroneous":false,"IsDeleted":false,"SensorId":null,"SpatialDataLso":null}


%Text%

Navigation: »No topics above this level«

Deleting import sessions

Last edited: 12/14/2017 6:43:50 AM

Import sessions can be deleted by the user who initiated them. Deleting an import session will not revert the changes the session introduced. The links between the import session and features or observations will be deleted but the features and observations themselves will remain.

Files that were associated with the import session will be deleted along with the import session.


Distance

Last edited: 10/25/2017 6:37:06 AM

This feature type represents the linear distance between two points.

Characteristic | Note
Unique ID | fb4aee6f-7fc3-44da-ab13-5421dccb13b7
Name | Distance with temperature
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | Point, Line
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type has no type specific feature dataThis feature type has no type specific feature data

Property structure for type specific observation data

Property, Property Collection | Description
Distance | Linear distance between two points Property type: Quantity of type Length Default Value: null Default Unit: m Validation rule: Value ≥ 0 Display Options: Decimals: 5
Temperature | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5
Zero reading | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Distance

Last edited: 10/25/2017 6:37:06 AM

This feature type represents the linear distance between two points.

Characteristic | Note
Name | Distance
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | Point, Line
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Distance DISTANCE | Linear distance between two points Property type: Quantity of type Length Default Value: null Default Unit: m Validation rule: Value ≥ 0 Display Options: Decimals: 5
Temperature TEMPERATURE | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Distance change

Last edited: 10/25/2017 6:37:06 AM

This feature type represents the linear distance between two points.

Characteristic | Note
Unique ID | 0D8EF527-C83D-491B-8DFA-6B4655FAE007
Name | Distance
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | Point, Line
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type has no type specific feature dataThis feature type has no type specific feature data

Property structure for type specific observation data

Property, Property Collection | Description
Distance | Linear distance between two points Property type: Quantity of type Length Default Value: null Default Unit: m Validation rule: Display Options: Decimals: 5
Temperature | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5
Zero reading | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure


Document folder

Last edited: 10/5/2017 11:51:14 AM

A Document Folder is a platform feature that can contain other document folders or documents.

Characteristic | Note
Name | Document folder
Path | \Document management
Feature type icon |
Feature type class | Platform
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | Document folder, Document

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

This feature type defines not property structure for extended observation


Documents

Last edited: 10/5/2017 11:51:14 AM

A document is a piece of digitized human knowledge in several versions. I.e. a document can have more than one file, each file representing a different version of the document.

Characteristic | Note
Name | Document
Path | \Document management
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection Identifier | Description
Keywords KEYWORDS | Keywords for this document Property type: Text Default Value: null Validation rule: Length <= 4000 Display Options: multi-line = true
Authors AUTHORS | Authors of the document Property type: Text Default Value: null Validation rule: Length <= 4000 Display Options: multi-line = true

Table 1: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

Property, Property Collection Identification | Description
File FILE | Stores a arbitrary binary file Property type: Binary Default Value: null Validation rule: Display Options:
Change history CHANGE_HISTORY | Document change history Property type: Text Default Value: null Validation rule: Length <= 4000 Display Options: multi-line = true
Authors AUTHORS | Authors of the document Property type: Text Default Value: null Validation rule: Length <= 4000 Display Options: multi-line = true

Table 2: Properties and collections of the type specific observation data property structure


Feature matching

Last edited: 12/11/2017 11:35:14 AM

When importing data Redbex has to match features found in the import sources against features already existing in Redbex, so that the feature data and observation data in the import sources can be imported to the right feature in Redbex and so that the import can determine what data shall be imported to features that are not yet in the Redbex.

The logic how features found in the import sources are matched to features already existing in Redbex is defined by the import type.


Feature privileges & permissions

Last edited: 11/8/2017 10:15:02 AM

Feature privileges i.e. privileges that have a feature as privilege object define permissions users have on a specific feature. The effective permission a user or user group has on a feature may also include permissions that are transformed from view permissions (of all views the feature is member of and all of their parent views) or inherited from the container permission the feature belongs to.

Using feature privileges allows extremely fine grained access control (on a per feature basis). While this might be useful in many cases, a more effective and dynamic way of controlling access to features is defining view privileges with permissions that are transformed to feature permissions for all members of the view.

Table 1 lists the permissions that are available when defining feature privileges

Permission

No

Description, Actual actions granted

Read (0)

0

If this permission is given the user can read the data of the feature (base data, type specific data, location data, relations, configuration data, ...). This does not imply read permissions on the observations of the feature.

Modify (1)

1

If this permission is given the user can modify the data of the feature excluding configuration data. Modification includes deletion of the feature itself, setting of the editing status of the feature, and starting of approval workflows. Modify permission does not include the permission to modify observation results.

Note that even if this permission is granted to a user a feature is protected against modification if it is in editing status ready.

Comment (2)

2

If this permission is given the user can write comments for a feature

Read observations (3)

3

If this permission is given the user can read the observations of a feature.

Modify observations (4)

4

If this permission is given the user can modify observation of the feature. This includes deletion of observations

Note that even if this permission is granted to a user an observation is protected against modification if it is in editing status ready.

Comment Observations (5)

5

If this permission is given the user can write comments for a feature's observations.

Observation monitoring (6)

6

If this permission is given the user can create observation monitoring definitions on that feature.

Manage (7)

7

The manage feature permission is kind of an elevated modify permission. Following data changes and functions are protected by this permission:

·Delete alarms

·Delete comments (on feature and observation, even if comment was issued by other user)

Modify privileges (8)

8

If this permission is granted the privileges on the feature can be modified. Still the modifying user can only modify feature privileges (add or remove) with a permission that the modifying user is granted himself.

Manage approval workflows (9)

9

If this permission is granted the user can abort and obsolete approval work flows applied to this feature or to observations of this feature.

Set approval obsolete (10)

10

Setting started approval work flows to obsolete.

Table 1: Permissions that can be granted to feature privilege objects

The permission to read the base data of features is the list permission. This permission is either granted by defining a privilege on a view with permission List features (2) or automatically granted by the system if a user has read permissions on a feature that relates to this feature.

If a feature is member of a platform it also inherits all privileges of that platform feature. Note that the platform relation is the only feature relation that will populate privileges to all related features.

A user creating a feature will be automatically granted the permission Read (0) on that feature.This behavior can be disabled with the instance configuration file.


Permissions for context settings

Last edited: 11/28/2017 11:08:26 AM

To modify settings that are applicable in a specific context the user has to have the appropriate permissions for that context. Table 1 lists the permissions needed for each feature context. Settings can be read by all users that have the appropriate permission in the given context

Context | Permissions needed
Feature | To define settings in the context of a specific feature the user must have the Modify (1) feature permission on that feature.
Domain + feature type + feature subtype | The user must have the domain permission Modify feature settings (15) on the selected domain the permissionModify feature settings (4) on the feature type.
Domain + feature type | The user must have the domain permission Modify feature settings (15) on the selected domain and the permissionModify feature settings (4) on the feature type.

Table 1: Permissions needed to create and modify feature settings with a specific feature setting context

To modify settings that are applicable in a specific sensor context the user has to have the appropriate permissions for that sensor context. Table 1 lists the permissions needed for each sensor context. Settings can be read by all users that have the appropriate permission in the given context

Context | Permissions needed
Sensor | To define settings in the context of a specific sensor the user must have the Modify sensor permission on that feature.
Domain + sensor type | The user must have the domain permission Modify feature settings on the selected domain for the selected feature type

Table 1: Permissions needed to create and modify feature settings with a specific feature setting context


Feature type privileges & permissions

Last edited: 11/8/2017 10:15:02 AM

Feature type privileges i.e. privileges that have a feature type as privilege object, define permissions users have on a specific feature type. The effective permissions a user has on a feature type cannot be inherited from another privilege object and cannot be transformed from another permission on another privilege object.

There are several indirect privilege objects that are referenced to specific feature types and to domains. The permission for accessing these objects is granted if the permission is granted on the feature type as well as on the domain. This allows you to assign permissions in a very flexible way.

Example: If you grant the permission to modify a classification that is used by a specific feature type this does not allow the privilege subject to modify any classification. Only if the same permission is also granted on a domain the privilege subject has the permission to modify classifications belonging to that feature type in that domain.

Table 1 lists the feature type permissions.

Permission | No | Description, Actual actions granted
Modify sensors (1) | 1 | Permission to create, modify and delete sensors that are of a sensor type which is linked to that feature type. To be allowed to actually create, modify or delete a sensor the user also needs modify sensors permission on the domain the sensor belongs to (or a parent domain)
Modify classifications (2) | 2 | Permission to create modify and delete classifications that are of a classification type which is used by that feature type. To be allowed to actually create, modify or delete a classification the user also needs modify classifications permission on the domain the classifications belongs to (or a parent domain).
Modify feature subtypes (3) | 3 | Permission to create modify and delete feature subtypes. To be allowed to actually create, modify or delete a feature subtype the user also needs modify feature subtypes permission on the domain the subtype belongs to (or a parent domain).
Modify feature settings (4) | 4 | Modify feature settings where the context is a feature setting with a context that reference this feature type. To be allowed to actually create, modify or delete a feature setting the user also needs modify feature settings permission on the domain the context references.
Modify sensor settings (5) | 5 | Modify sensor settings where the context is a sensor of a type that is referenced to that feature type. To be allowed to actually create, modify or delete a sensor setting the user also needs modify sensor settings permission on the domain the context references.
Create features (6) | 6 | If granted the privilege subject can create features of this type. To be allowed to actually create, features in a domain the user also needs the on the domain the context references.

Table 1: Permissions on feature types


Landregister area

Last edited: 10/30/2017 8:45:24 AM

This feature type represents a collection of lots. The actual meaning depends on the usage, is some scenarios this might be a block in others part of a district etc.

Characteristic | Note
Name | Land register area
Path | \Land register
Feature type icon |
Feature type class | Platform
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | Projected coordinate system
Allowed geometries | Polygon, Multi-Polygon
Allowed contained feature types | Lot

Property structure for type specific feature data

Property, Property Collection Identifier | Description
Obsolete Obsolet | Defines if the area is obsolete, i.e. no longer in use. Property type: Boolean Default value: false
County Län | County to which the area belongs Property type: Classification of type County
Municipality Kommun | Short code of the community to which the area belongs Property type: Classification of type Land register municipality Default Value: null
District Trakt | District to which the area belongs Property type: String Default Value: null
Block Block | Block to which the area belongs Property type: String Default Value: null
Version date Versionsdatum | Last change of the block's data. This can be used to detect updated data during import.

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Landregister Block

Last edited: 10/30/2017 2:38:52 PM

Characteristic | Note
Name | Block
Path | \Land register
Feature type icon |
Feature type class | Platform
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | Projected coordinate system
Allowed geometries | Polygon, Multi-Polygon
Allowed contained feature types | Lot

Property structure for type specific feature data

Fastighet detail type is used all others shall be skipped! (Alternatively add a import setting to allow the user to select.

How to format the (unique blockname?)

CommunityName + " " + Trakt + (string.IsNullOrWhitespace(Blockeneht) ? "" : " " + Block&enhet)

Property with FNR_FDS = 0 has not Blockenhet!

Unique indentife for a block is

CommunityName+Trakt + Block (e.g. Citybanan)

CommunityName+Trakt (e.g. in E4)

The user will have to choose this on import

Property, Property Collection Identifier | Description
Local name | A local name for the block
Country code LAN_KOD | Short code of the Country (I guess) I guess there would be only a small number of countries, int that case I would suggest a classification where code is this kod and name is a more speaking name (also better for searching)
Community code Kommunkod | Short code of the community the block belongs to Property type: String (or number?) Default Value: null Classification? If yes how many communities are there (approx) - Oher feature type?
Community name Kommunnamn | Name of the community the Property type: String Default Value: null See above
District Trakt | District within the community that the block belongs to Property type: String Default Value: null
BlockId Blockenhet | Name of the block. Property type: String Default Value: null The blockenhet seems to have a special syntax it can be a single number or two numbers sparated by a colon. Shall these 2 be separated and imported as two different numeric values? What is the meaning of the two numbers? Only use everything before the colon
Version date Versionsdatum | Last change of the block's data. Calculate this as MAX(ADAT)?

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Surface object

Last edited: 10/5/2017 11:51:20 AM

Represents an object on the surface.

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Volumetric flow rate

Last edited: 10/25/2017 6:37:06 AM

Represents the volume of fluid passing though a given surface per unit time.

Characteristic | Note
Unique ID | 5b9001f2-08a9-4461-80bf-a2e3d59659fb
Name | Volumetric flow rate
Path | \Hydrology
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed geometries | ?
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
Sampling location | General remarks Property Type: Text Default Value: none Display Options: Multi line

Table 2: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

Property, Property Collection | Description
Delivery | Amount of water delivered Property type: Quantity of type Volume / Time Default Value: null Default Unit: m³ / s Validation rule: Value ≥ 0 Display Options: Decimals: 2
Temperature | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5
Zero reading | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 3: Properties and collections of the type specific observation data property structure


Surface object

Last edited: 10/25/2017 6:37:06 AM

Represents an object on the surface.

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


%Text%

Navigation: »No topics above this level«

TMO building

Last edited: 10/5/2017 11:51:20 AM

Represents a building with attributes as defined in the TMO System.

Characteristic | Note
Name | TMO Building
Path | \Land register
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on feature
Allowed spatial systems | Projected, Geographic
Allowed geometries | All
Allowed contained feature types | All

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection Identifier | Description
Grundvattenberoende grundläggning DependentOnGroundWater | Indicates whether the foundation of the building is influenced by the ground water. Property type: Boolean Default Value: null
Grundvattenberoende övre magasin DependentOnUpperAquifer | Indicates whether the foundation of the building is influenced by the upper aquifer. Property type: Boolean Default Value: null
Grundvattenberoende undre magasin DependentOnLowerAquifer | Indicates whether the foundation of the building is influenced by the lower aquifer. Property type: Boolean Default Value: null
Grundvattenberoende källargolv på lermark FoundedOnClaySoils | Indicates whether the foundation of the building is influenced by clay (foundations are in clay). Property type: Boolean Default Value: null
Grundvattenberoende servisledningar GroundwaterDependentServiceLines | Indicates whether the service lines to and form a building are influenced by ground water situation Property type: Boolean Default Value: null
Byggnadstyp BuildingType | Building type Property type: String Default Value: Validation rule: Max Length: 2000 Display Options: Multi-line text: yes
Adress Address | Address of the building Property type: String Default Value: Validation rule: Max Length: 2000 Display Options: Multi-line text: yes
Byggår YearBuilt | Year when the building was constructed Property type: Numeric Default Value: null Validation rule: none Display Options: Integer places: 4, Decimal places: 0
Våningar över mark FloorsAboveGround | Number of above-ground-floors of the building Property type: Numeric Default Value: null Validation rule: none Display Options: Integer places: 3, Decimal places: 0
Våningar under mark FloorsBelowGround | Number of below-ground-floors of the building Property type: Numeric Default Value: null Validation rule: none Display Options: Integer places: 2, Decimal places: 0
Grundläggningskategori FoundationsCategory | Defines the type of foundation used with this building Multi-Classification of type FoundationCategory
Grundläggning kommentar FoundationsComment | Comments on the building's foundations Property type: String Default Value: Validation rule: Max Length: 2000 Display Options: Multi-line text: yes
Grundförstärkning ReinforcementsOfFoundations | Extra support for the foundations Collection (see table 3 below)
Lägsta nivå ök källargolv MinimumLevelBasementFloors | Minimum level of the basement floor Given in absolute elevation. Property type: Numeric Default Value: null Validation rule: none Display Options: Integer places: 3, Decimal places: 3
Kommentar on minimum level CommentOnMinimumLevel | Comment on Minimum level Property type: String Default Value: Validation rule: Max Length: 2000 Display Options: Multi-line text: yes
Nivå ök rustbädd LevelRustBed | Nieveau of rustbädd (acient method for foundations of buildings) Property type: Numeric Default Value: null Validation rule: none Display Options: Integer places: 3, Decimal places: 3
Kommentar rustbädd CommentOnRustBed | Property type: String Default Value: Validation rule: Max Length: 2000 Display Options: Multi-line text: yes
Nivå ök pålavskärning LevelCutting | Upper level of the pile cut Property type: Numeric Default Value: null Validation rule: none Display Options: Integer places: 3, Decimal places: 3
Kommentar pålavskärning CommentOnLevelCutting | Property type: String Default Value: Validation rule: Max Length: 2000 Display Options: Multi-line text: yes
Jordlagerbeskrivning SoilLayerDescription | Description of soil layer Property type: String Default Value: Validation rule: Max Length: 2000 Display Options: Multi-line text: yes
Källor Resources | Sources from which information for this building was gathered. Property type: String Default Value: Validation rule: Max Length: 2000 Display Options: Multi-line text: yes

Table 2: Properties and collections of the type specific feature data property structure

Property, Property Collection Identifier | Description
Grundförstärkning ReinforcementType | Type of foundation support applied Property type: String Default Value: Validation rule: Max Length: 2000 Display Options: Multi-line text: yes
Year from FoundationSupportFrom | Year when the building was applied Property type: Numeric Default Value: null Validation rule: none Display Options: Integer places: 4, Decimal places: 0
Year to FoundationSupportTo | Year when the building was removed Property type: Numeric Default Value: null Validation rule: none Display Options: Integer places: 4, Decimal places: 0

Table 3: Properties of the foundation support collection

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Generic single numeric SSF

This feature type is a generic feature type to be used for all phenomenon where the observation result of a single observation is a single numeric value.

Characteristic | Note
Unique ID | 65c9044f-4fe5-4b6b-843d-d96f1a2ee63a
Name | Generic single numeric SSF
Path | \Generic
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed Geometry types | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type has no type specific feature data

Property structure for type specific observation data

Property, Property Collection | Description
Numeric value | Numeric value Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5

Table 2: Properties and collections of the type specific observation data property structure


Generic single numeric SSO

Last edited: 10/25/2017 6:37:06 AM

This feature type is a generic feature type to be used for all phenomenon where the observation result of a single observation is a single numeric value.

Characteristic | Note
Unique ID | 0c171189-071c-4d59-816f-c4a56606d35d
Name | Generic single numeric SSF
Path | \Generic
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed Geometry types | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type has no type specific feature data

Property structure for type specific observation data

Property, Property Collection | Description
Numeric value | Numeric value Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5

Table 2: Properties and collections of the type specific observation data property structure


Geological round 001

Last edited: 10/5/2017 11:51:22 AM

Please note, that the Feature Type for documentation of geological heading face situation always will be taylored to the needs of the project. The following gives an example and shall be seen as a template:

Represents the geological situation at the heading face of a cyclical tunneling project. This feature type is tailored to the usual needs of a geological documentation in a hard rock environment.

Characteristic | Note
Name | Geological situation at headingface 001
Path | \Tunneling
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on observation
Allowed spatial systems | Axis
Allowed geometries | N/A
Allowed contained feature types | None

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

The property structure for type specific observation data of this feature type is a rich structure containing multiple collections. Figure 1 shows a graphical representation of this property structure.

Figure 1: The structure of the type specific data for observations.

Property Identifying name | Description
Round length ROUNDLENGTH | Describes the geologic situation for rounds in a tunnel drive. This feature type is tailored for use in a hard rock environment. Property type: Numeric Default Value: null Validation rule: >= 0
Round number ROUNDNUMBER | Number of the documented round. Property type: Numeric Default Value: null
General notes GENERALNOTES | General notes on the geologic situation. Property type: String
Notes on rock mass ROCKMASSNOTES | Notes on the surrounding rock mass. Property type: String
Notes on rock mass behaviour ROCKMASSBEHAVIOURNOTES | Notes on the behaviour of the surrounding rock mass on excavation. Property type: String
Rock notes ROCKNOTES | Notes on the rock. Property type: String
Heading face sketch HEADINGFACESKETCH | Sketch of the geological situation at the heading face of this round. Property type: Referenced Image
Sketch notes HEADINGFACESKETCHNOTES | Notes on the heading face sketch. Property type: String
Profile accuracy PROFILEACCURACY | Accuracy of the excavation in relation to the planned excavation geometry. Property type: Classification
Advance type ADVANCETYPE | Defines how the tunnel was excavated in this round. Property type: Classification

Table 2: Level 0 properties of this feature type.

Lithology

Documentation of lithological units of this round.

Property Identifying name | Description
Notes NOTES | General notes on the lithological unit. Property type: String
Color COLOR | Description of the color of the lithological unit. Property type: String
Geometry GEOMETRY | Geometry of the lithological unit on the heading face. Property type: Geometry
Dipping DIPPING | Dipping of the lithological unit. Property type: Numeric
Dipping direction DIPPINGDIRECTION | Line of greatest inclination to the horizontal. Property type: Numeric
Fragmentation FRAGMENTATION | Physical fragmentation of rocks. Property type: Classification
Water sensitivity WATERSENSITIVITY | Influence of water on the chemical and physical characteristics of the rock. Property type: Classification
Weathering WEATHERING | Encompasses all reactions of the rock to exegenous factors. Property type: Classification
Geologic unit GEOLOGICALUNIT | The geologic unit this lithological unit belongs to. Property type: Classification
Rock ROCK | The main rock type that characterizes this lithological unit. Property type: Classification
Rock strength ROCKSTRENGTH | Classification of the lithological unit regarding its strength on pressure, tensile strength, shearing strength, and other factors. Property type: Classification
Granular binging GRANULARBINDING | Classification of the lithological unit regarding the binding of granular material. Property type: Classification
Bedding BEDDING | Classification of the lithological unit regarding its bedding. Property type: Classification
Tectonic unit TECTONICUNIT | Tectonic unit this lithological unit is associated with. Property type: Classification
Stratigraphic unit STRATIGRAPHICUNIT | Stratigraphic unite this lithological unit is associated with. Property type: Classification
Formation strength FORMATIONSTRENGTH | Cohesiveness of rock that is totally divided by discontinuites. Property type: Classification
Intercalation INTERCALATION | Intercalation in rock. Property type: Classification

Table 3: Properties of elements in the lithology collection

Dicontinuities

Documentation of discontinuities in this round.

Property Identifying name | Description
Description DESCRIPTION | Description of the discontinuity unit. Property type: String
Location description LOCATIONDESCRIPTION | Description of position, shape and and orientation of the discontinuity unit. Property type: String
Geometry GEOMETRY | Geometry of this discontinuity unit on the heading face. Property type: Geometry
Dipping DIPPING | Dipping of the discontinuities in this unit. Property type: Numeric
Dipping direction DIPPINGDIRECTION | Line of greatest inclination to the horizontal Property type: Numeric
Genesis GENESIS | Classification of this discontinuity unit regarding to its genesis. Property type: Classification
Aperture APERTURE | Classification of this discontinuity unit regarding to the aperture. If the discontinuities are filled this describes the thickness of the filling. Property type: Classification
Spacing SPACING | Classification of this discontinuity unit regarding to the spacing between two discontinuities in this unit. Property type: Classification
Filling FILLING | Material that fills the discontinuity. Property type: Classification
Gouge GOUGE | Gouge that is found on the discontinuity. Property type: Classification
ASPERITY ASPERITY | Macroscopic description of the difference to a totally flat structure. Property type: Classification
ROUGHNESS ROUGHNESS | Microscopic description of the difference to a totally flat structure. Property type: Classification

Table 4: Properties of elements in the discontinuities collection

Water influx

Documentation of water influx.

Property Identifying name | Description
Notes NOTES | General notes on this water influx. Property type: String
Geometry GEOMETRY | Geometry of this influx at the heading face. Property type: Geometry
Leakage type LEAKAGETYPE | Property type: Classification
Leakage behaviour LEAKAGEBEHAVIOUR | Property type: Classification
Influx type INFLUXTYPE | Property type: Classification
Influx character INFLUXCHARACTER | Property type: Classification
Influx place INFLUXPLACE | Property type: Classification

Table 5: Properties of elements in the water influx collection

Rock mass

Documentation of the rock mass in this round.

Property Identifying name | Description
Geometry GEOMETRY | Geometry of this rock mass unit on the heading face. Property type: Geometry
Rock mass type ROCKMASSTYPE | Classification of this rock mass unit regarding its type. Property type: Classification
Rock mass behaviour ROCKMASSBEHAVIOUR | Classification of this rock mass unit regarding its behaviour on excavation. Property type: Classification

Table 6: Properties of elements in the rock mass collection

Samples

Documentation of samples

Property Identifying name | Description
Geometry GEOMETRY | Position of sample on the heading face. Property type: Geometry
Notes NOTES | General notes on the sample. Property type: String
Sample number SAMPLENUMBER | Number or ID of the sample. Property type: String
Sample type SAMPLETYPE | Classifies the sample according to its type. Property type: Classification

Table 7: Properties of elements in the samples collection


Globalization and Localization

Last edited: 10/25/2017 6:37:06 AM

Redbex is a world-ready application, i.e. it considers numerous factors, such as languages issues, date format issues and other string-related issues. However you can configure Redbex in may ways to meet your local requirements.


Feature matching

Last edited: 12/14/2017 6:43:50 AM

When importing data Redbex has to match features found in the import sources against features already existing in Redbex, so that the feature data and observation data in the import sources can be imported to the right feature in Redbex and so that the import can determine what data shall be imported to features that are not yet in the Redbex.

The actual logic how features found in the import sources are matched to features already existing in Redbex is defined by the import type. However all import types have the same basic logic:

The import will only search for matches in the set of features that are member of the same data domain as the target data domain set in the import definition (including all sub-domains). Additionally only those feature will match where the feature type is the same as the feature type the import type suggests for the data in the sources.


Landmateriet

Last edited: 10/25/2017 6:37:06 AM

All steps are performed only for the geometrical area for which the import was started

·Import/Update blocks

·Import/Update lots (and build platform relation to block)

·Import/Update TMO Buildings (and build platform relation to block)

·Set a flag for non exisiting TMO Buildings (instead of delete)

·Set a flag on non existing lots

·Set a flag on non existing blocks


Importing lots

Last edited: 11/8/2017 10:15:02 AM

Determining lots

In the source database for this import a lot is not defined as an entity but lots are created by the importer by grouping lot-parts. The geometry of a lot is calculated as the geometrical union of all lot-parts.

The region filter for the import will be applied after the geometrical union of areas has been calculated. Therefore all lots that intersect the region filter (in other words where any of its base areas intersect the region filter) will be imported.

Areas have a Detaljtyp. When unioning areas to lots only areas with the same Detaljtyp will be unioned. Therefore lots also have a Detaljtyp. Note that lots with different Detaljtyp can be geometrically overlapping.

How will lots be matched against existing Redbex features

During the import the importer checks the lots it finds in the source against the lots that already exist in Redbex. This is done by checking feature names of all features of type Landregister lot that are within the target domain (or one of its sub-domains), have the same coordinate system as the target coordinate system specified in the import settings, and whose LSO is intersecting the are within the region feature specified in the import setting.

Obsoleting non-existing lots

Lots that are found in Redbex but are not present in the Lantmäteriet database (using the matching described above) can be optionally set as obsolete (i.e. the obsolete attribute of the lot is set to true.

Questions

·Searching for lots in the source database will become slower as the source database contains more data. I don't know if the source database has any index on the shape of lot-parts that could be used. If yes first filtering and then unioning would be much faster than the other way around. HOwever this might result in incomplete lots.
Suggestion: Allow incomplete lots to speed up things.
We are aware of this problem but do not handle it since this will bve just a few cases and these lots are usually not interesting as they are at the boundary. User can always increase the import area.

·How to we differentiate with lots of different Detaljtyp in Redbex? Suggestion: Use feature subtype -> This makes things easily filterable. This means that the subtypes have to be created before the import is run. Custom symbols can then help to distinguish diffent Detaljtyp in feature explorer etc.
If this siutuation really happens then add the Detaljtyp to the feature name to make i unique

·FNR_FDS is not necessarily unique over Detaljtyp. Identity domains might not work.

o Option 1: Change definition of identity domain to be unique by feature subtype not only feature type

o Option 2: Put Detaljtyp to name

o Option 3: Don't care about uniqueness

·Lot with FNR_FDS = 0? is this really a lot to be imported? - this makes problems: Suggestion ignore these lots from the beginning
FNR_FDS = 0 will not be imported

·Naming of lots: Lots are named by thier (hopefully unique FNR_FDS nr.)

Lots and Areas

Areas are subdivisions of lots. To get the geometry of a lot all its areas must be geometrically unioned.

·In the FK_AY table the columns FNR_FDS and OMRNR uniquely define an area.

·One ore more areas can be linked to the same lot.

·Each area has its own geometry therefore one lot can have multiple geometries and we need to union them

·The atomic unit we are importing is the lot and not the area

·Each area has a adat value that tells us when this was last updated this field can be used for optimizing the import Use Max (ADAT) of all areas of a lot to get the latest version of a lot

Import of just a subset

To save storage space and processing time only a subset of properties, blocks and buildings shall be imported. The subset is defined with a polygon geometry that is defined by a Redbex Region feature.

A property, block, building is imported if it intersects with the provided region polygon. NOTE: First union areas an only then apply the filter.

Check if a property is already in Redbex

Properties are identified by the unique (FNR_FDS) this will be used to check for existing properties. -> FNR_FDS will become the feature name in Redbex

Check if FK database contains updated properties

·Use Adat (if needed)

·Max(Adat) for all areas of one real estat gives us the latest modification time of the real estate.

Deleting lots in Redbex.

For all lots in Redbex that are within the import region and that have a FNR_FDS not found with in the (region filtered) FK_AY table delete that lot property.

Do this only based on a switch in the import settings.

Attributes to be imported

Property, Property Collection Identifier | Import? | Description
OBJECTID | Yes | Internal Universally unique identity (UUID) for the real property. Not true This is the id for the area not for the property!
FNR_FDS | Yes | Official Property number (not unique) Real property key in the Real Property Register (210002312)
OMRNR | No | Is 0 = null? Area number (3). 0 is treated as an empty value
EXTERNID | No | Do we need this in Redbex Does the content have any specific format? Split? External ID from Lantmäteriets basic data. Taken from the AI layer. For share in an unregistered joint property unit EXTERNID=ANDELSFASTIGHET.
DETALJTYP | Yes | Real names for this? Is this a fixed classification? Aggregation? Detail type code (FASTIGHET, SAMF, FASTO, SAMFO) Classification
KOMMUNKOD | Yes | County and municipality code (2180)
KOMMUNNAMN | Yes | Municipality name (GÄVLE)
TRAKT | Yes | District name (BY)
BLOCKENHET | NO | This thogether with Kommunnam Kommunkod, Trakt specifies the block to which the property belongs. For the trackt Block and unit (1:3)
FASTIGHET | NO | Split? Real property area: District_block:unit_area number (BY 1:3>3)
YTKVAL | YES | Geometric quality of polygons. Values: 1,2,6. 0 is treated as an empty value. See detailed description below. Aggregation? Classification translation? Classification!
ADAT | YES | Date/time of most recent change. Note, does not need to be latest revision. Format: 2005-10-18 12:04 Use maximum of ADAT for all areas within a property
FASTIGHETBV | No | Values: Oregistrerad samfällighet or empty value
LAN_KOD | YES | County code (next after community) Probably a Classification
IMPORTDATUM | No | This is the the date when the data was transferred to the TVKT database
Shape | Yes | Union aggregate


Import definition

Last edited: 12/14/2017 6:43:50 AM

To import data you first have to create an import definition. The import definition advices the Application Server where it can find the data to be imported and how this data shall be processed during import.

Import definitions can be created on-the-fly or can be persisted as import templates for repeated execution.

Import templates are import definitions that are persisted on the Application Server in the context of a domain. You will typically create import templates when you intend to repeatedly execute that import definition with different or changed data sources.

Import templates can either be private or public. Private import templates are visible only for the user who created them. Public import templates are visible to all users who have domain permission Read (0) on the domain the import template is associated with. To create modify or delete public import definitions users must have the Manage import definitions (20) permission.

An import definition will always import data into one specific domain. I.e. if the import creates new features those features will always belong to the same domain.

An import definition consists of:

·Specification of import type

·Name and description of the import definition (only for stored import definitions)

·Specification of data sources (e.g. files, other databases)

·Specification of common settings (settings available for all imports disregarding the import type)

·Specification of import settings specific to the chosen import type

·Specification of the import source from which data is imported

Setting name

Description

General

Target domain

This is a mandatory setting.

Each import session created from an import definition must target a specific domain. This domain will be used for following:

·Resolve feature that are already in Redbex

·Find alias schemes

·Domain for newly created features

Create new features

If set, the import session will create new features (and if present their observations) found in the import data sources. If not set new features (and again their observations) will not be created.

The import type decides what is a new feature by trying to match features found in the sources against features already existing in Redbex. The logic for this matching is different for each feature type.

Overwrite existing observations

If set, data of already existing observations (observations with the same sampling time as an observation in the import source) stamp will be overwritten with the data from the import source.

Overwrite existing features

If set, data for already existing features (features in Redbex that could be mapped to the features found in the import source with the logic of the import type) will be updated with the data from the import source

Import session name

The identifying name that will be used for all import sessions that are created from this import definition. This setting is optional but is useful when tracking import logs etc.

If no import session name is defined the Application Server will choose a default name.

Import session description

Description that will be added to all import sessions that are created from this import definition. This setting is optional but is useful when tracking import logs etc.

Time conversion

Settings in this group are used to define how the Application Server shall handle Date-Time values read from the source(s) when converting them to Date-Time-Offset.

Conversion type

Defines which conversion type shall be used when converting Date-Time values. Two options are available:

·Time zone: With Time Zone conversion Date-Time values are interpreted using the Time Zone defined in the Time Zone setting.

·Fixed offset: With Fixed offset conversion Date-Time values are interpreted using a fixed offset. I.e. all Date-Time values in the source are assumed to have the same offset from UTC.

Time Zone

This setting is only effective if Conversion type (see above) is set to Time Zone.

Defines the time zone used to convert Date-Time values to Date-Time Offset Values.

Default: Application Server's Operating System Time zone.

Fixed offset

This setting is only effective if Conversion type (see above) is set to Fixed Offset.

Defines a time span (in minutes) that is used to convert Date-Time values to Date-Time Offset Values.

Default: Application Server's Operating System Current Time Offset..

Advanced settings

Settings in this group are usually only for advanced users, they allow you to fine tune your import definition.

Alias scheme

This is an optional setting.

Defines the alias scheme to be used for resolving feature names found in the source files. If no alias scheme is given the Application Server will resolve feature names in the source files with the real feature names stored on the Application Server

Skip errors

If enabled the import will skip errors if possible, if not enabled the import will break if an error is detected, e.g. when reading a malformed source file.

Default: False

Break after conversion

If set the import definition will not actually create or modify features or observations but the import will break after the data was read from the import sources. This setting is useful when trying to read data from a new source since it will report all errors during reading from that source and will not create any features or observations.

Default: False

Edit mode setting

Can be used to set the edit mode of newly created observations.

Default: None

Table 1: General settings available with all import formats

Setting | Description
Settings for stored import definitions (only used when persisting the import definition as stored import definition)
Name | Name of the import definition. This can be empty for on-the-fly imports.
Grouping path | The path that can be used by clients to display stored import definitions in a tree-like structure.
Description | Description of the import definition.
Private | If set the stored import definition will be private to the user who created it.
Origin domain | The domain that the stored import definition is associated with. Note that an import definition might be associated with one domain, but might still import data for another domain.

Table 2: Settings for stored import definitions


Import sessions

Last edited: 12/14/2017 6:43:50 AM

Whenever a import definition is executed an import session is created on the Application Server. Import sessions therefore provide a history of data imports performed from a specific import definition.

Import definitions that have not been persisted as import templates before the definition was executed will record the import session as On-the-fly import session. Imports executed from stored import definitions will record the import session linked to that stored import definition.

Linking of features and observations to import sessions

All features and all observations that are created during an import are linked to that import session. Note: If an observations is updated by an import session the old observation is actually deleted and then a new observation is created. The linking of features and observations to import sessions is used by Redbex

Source files

Import sessions for import types that read data from files can optionally store the original source files. If source files were stored with an import session the user may delete those source files at a later point in time without deleting the import session or deleting the data created or modified by the import session.


Importing areas

Last edited: 11/8/2017 10:15:02 AM

Determining blocks

In the source database for this import a block is not defined as an entity but blocks are created by the import procedure by grouping lots according to a chosen block creation strategy (type specific import setting). Available strategies are shown in table 1. The geometry of a block is calculated as the geometrical union of all lots in that block.

Strategy

Description

Community name + District name + Block name

This strategy in this list will create more blocks and is therefore better suited for densely populated areas.

Technically this creates blocks by grouping lots like this

GROUP BY
LAN_KOD, KOMMUNKOD, KOMMUNNAMN, TRAKT, IIF(CHARINDEX(':', BLOCKENHET) > 0,
SUBSTRING(BLOCKENHET,
0,
CHARINDEX(':', BLOCKENHET)),
BLOCKENHET)

Community name + District name

This strategy will create less but bigger blocks and is therefore better suited for rural areas.

Group BY LAN_KOD, KOMMUNKOD, KOMMUNNAMN, TRAKT

Table 1: Block creation strategies

Which data from the source will be processed

A block is created by geometrically unioning all lots with the same characteristics according to the chosen community name. Only those lots are processed, that are intersecting with the given boundary. It might therefore be that blocks are smaller than the real world block.

How will blocks be matched against existing Redbex features

During the import the importer checks the blocks it finds in the source against the blocks that already exist in Redbex. This is done by checking feature names of all features of type Landregister block that are within the target domain (or one of its sub-domains), have the same coordinate system as the target coordinate system specified in the import settings, and whose LSO is intersecting the are within the region feature specified in the import setting.

Open questions

Since we have different lot detaljtyp that may define overlapping lots we also have different area detaljtype (that might also be overlapping)

·Shall we import differnt block detaljtyps or only FASTIGHET
Do not use Detaljtyp

·If we import: How do we encode different Detaljtype: Suggestion we use feature subtype. Same uniqueness problems as with lots


Importing buildings

Last edited: 11/8/2017 10:15:02 AM

The major part of the buildings has a geometry that has been established in a survey, either by geodetic or photogrammetric methods. The attribute INSAM_LAGE for these buildings has the value “roof-edge” or “facade” depending on where on the building the position was captured. But there are also buildings whose shape or position is merely an illustration. In this case the attribute INSAM_LAGE has the value “illustrative location.”

Questions:

There is no unique name for buildings except the objekt_Id therefore in Redbex we see many buildings with exactly the same name. This will be problematic for the users. I do not see a way to uniquely name the objects across import session

1st Import session

Objekt Id | Nr
32F443B5-5B01-4B8A-8818-D06207A58677 | 1
6717BCFD-8B80-43DE-B24A-8A64F6613F51 | 2
8C0F5540-71EB-410E-86FF-73E6366DBBCF | 3

2nd Import session

Objekt Id | Nr
32F443B5-5B01-4B8A-8818-D06207A58677 | 1
6717BCFD-8B80-43DE-B24A-8A64F6613F51 | 2
70A41DFA-E900-44BC-8DF8-FF226C35DA1B | 3
8C0F5540-71EB-410E-86FF-73E6366DBBCF | 4

Possible solution: Naming scheme:

HALLUNDA 4:34 (BOTKYRKA) [8C0F5540-71EB-410E-86FF-73E6366DBBCF]

Still open

·Is it ok to use the Objekt_ID as part of the feature name

·Should we rename the TMO building to the standard implied by the Lantmäteriet import (keeping the local copy it to description)?

Check if building is already in Redbex

When importing a building that building might already be in Redbex (from TMO or some other import). To prevent duplicates following checks shall be implemented:

Algorithm

If a building with the same object id is in Redbex -> obvious (object id is not written by TMO!)

For all buildings that do not have an object ID in Redbex:

For each building in Redbex where objectID is null check if the area of the intersection of the building with the building to be imported is

IA > 0 and IA / NA > 0.9

Attributes

In Redbex Buildings are represented as features of type TMO building (this name might be changed in future)

Attribute | Import? | Description
OBJEKT_ID | YES | Globally unique identifier (UUID) for each building
OBJEKT_VER |  | Sets the version of the building. The service delivers the latest version of the building.
DETALJTYP |  | Detail type code
ADAT |  | Date/time of most recent change. Note, may not be the latest revision. Format: 2005-10-18 12:04
INSAM_LAGE |  | Specifies how the position of the building area is selected. Code Description: ·0 Unspecified location ·1 Facade ·3 Roof edge ·4 Illustrative location
XYFEL |  | Standard error. Given in mm. The value varies between 25 and 999,999 mm. 0 is treated as an empty value.
NAMN1 .. Nam3 | YES (for name 1) | The name of the building no. 1 Existing TMO buidlings already have a Name (given from community). Therefore this names shall not overwrite this. For newly created objects it would be good to find a short descriptive but still unique name. Used before: LANID, CommunityID and sequential number SW_MEMBER, RIDREGBY
HUVUDBYGGN |  | This defines the building as a main building, boolean switch Pointing out the main building within a larger complex of buildings on a real property.
ANDAMAL_1 |  | Main purpose of the building.
ANDAMAL_1T |  | Descriptive text to the buildings main purpose.
ANDAMAL_2 .. ANDAMAL_10 |  | Building purpose


Application Server directory

Last edited: 12/14/2017 6:43:50 AM

This source type is used to specify files located a directory on the Application Server. This source type may be useful in a single computer installation scenario or when the source files are put on Application Server via FTP Server, shared network storage etc.

This source type will process all files in a specified directory (a directory on the Application Server or a directory that can be accessed from the Application Server) that the given file mask. Additionally a date and time can be given to limit the files to files that were update after that given timestamp.

Table 1 lists the settings available for this source type. Note that the directory specified will be accessed as the Windows User running the Application Server Windows Service. Be sure to set the Windows access rights to the specified directory accordingly.

Setting | Description
Path | Path on the local file system or UNC path to a folder in the local network.
File mask | Regular expression defining which files shall be imported, if empty all files will be imported
Minimum last update date | The minimum last updated time stamp a file must have to be imported. Use this setting to skip old files in a directory.

Table 1: Settings for the Application Server directory source


%Text%

Navigation: »No topics above this level«

Database

Last edited: 12/14/2017 6:44:00 AM

This source type is used to a connection to a database from which the Application Server can directly gather data. This import source in only supported by some specific import type.

This import source stores a connection string to a database.


File Depot

Last edited: 12/14/2017 6:43:50 AM

This source type allows to specify files from the user's file depot as source files for the import. Once the import processed files from the upload vault they are automatically removed from the file depot.

This source specification cannot be used for stored import definitions (the specification will not be persisted). However it is useful in in on-the-fly import definitions.


FTP

Last edited: 12/14/2017 6:43:50 AM

This source type is used to specify files located on an FTP server (and that are therefore accessible through the FTP protocol) as source files for the import.

The connection to the specified FTP Server will be created from the Application Server. Therefore it is necessary that the Global Settings for FTP connections are set correctly.

This source type will process all files on a specified FTP server in a specified directory on that server that match the given file mask. Additionally a date and time can be given to limit the files to files that were update after that given timestamp.

The Application Server supports the option to only import files that were changed after the last execution of the import definition. The option Only files modified after last import is of course only respected for stored import sessions. If set this option will advice the Application Server to import data only from files that were modified after the last successful import session was started.

The Only files modified after last import option uses the last update time stamp provided by the FTP Server to decide if a file shall be imported or not. Only files with a last modification timestamp that is greater than the timestamp when the last successful import session was started will be downloaded and imported. Note that some FTP Servers do not always provide precise values for date & time and do not support date-time-offset values. Therefore it may be that this option behaves not as wanted especially when FTP Server and Application Server are in different time zones.

Table 1 lists the settings that are available for an import source of type FTP.

Setting | Description
Server | The DNS name or IP address of the FTP server
Port | The FTP Server's Port
Passive | Defines if passive FTP mode shall be used when connecting to the FTP server.
Timeout | Timeout in [s] for FTP commands
Username | The username to use for authentication on the FTP server.
Password | The password to use for authentication on the FTP server. The password is stored within the Application Server as symmetrically encrypted string.
Path | Path on the FTP server where the files to be imported are located.
File mask | A regular expression defining which files shall be imported, if empty all files will be processed.
Minimum last update date | The minimum last updated time stamp a file must have to be imported.
Only files modified after last import | Only useful for stored import definitions. If true, only files that were changed after the begin of the last import session will be processed

Table 1: Settings for the FTP source


Import source types

Navigation: »No topics above this level«

Import sources

Last edited: 12/14/2017 6:43:50 AM

There are different types of sources from which the Application Server can fetch the files to be processed in an import session. Table 1 summarizes these different source type.

Source option | Description
File Sources (source for import is one or more files in a specific format)
File depot | This source type can be used to import from files from a user's file depot. This source type will not be persisted in stored import definitions, but is available for on-the-fly import definitions.
FTP server | This source type is used to import from files located on an FTP server .
Application Server directory | This source type is used to import from located in a directory of the Application Server.
Databases
Database | Generic database source. Can be used only for import types that support reading data from another database.

Table 1: Source types for import files


3D Movement in Tunnel

Last edited: 12/11/2017 11:35:14 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


%Text%

Navigation: »No topics above this level«

Generic (customizable)

Last edited: 12/11/2017 11:35:14 AM

This import format is a generic format that can be used to import features and observations data for any feature type. It can read data from a wide range of tabular-structured data files, by allowing you to define which column in the source file contains what information as well as many other settings. This import type gives you great flexibility to adapt to the structure of a given source file.

The file format expected by generic import type is a text file structured in lines and columns. The import type will try to detect the encoding of the source files automatically. Listing 1 shows the supported encodings.

A line in the source file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Leading and trailing white space characters (see table 1) will be automatically trimmed from each line. If the column separator is set to tab (U+0009) tabs will not be trimmed. The first character of a line is defined as the first non-white space character, the last character as the last non-white space character.

Lines where the first characters (after trimming) equals the user-defined Comment Designator (see table 2) are treated as comment lines and will be ignored. If a comment designator is contained in a line, but is not the first character in the line it will be treated as data.

·UTF-8

·UTF-16 (BE and LE)

·UTF-32 (BE and LE)

·windows-1252 (mostly equivalent to iso8859-1)

·windows-1251 and ISO-8859-5 (cyrillic)

·windows-1253 and ISO-8859-7 (greek)

·windows-1255 (logical hebrew. Includes ISO-8859-8-I and most of x-mac-hebrew)

·ISO-8859-8 (visual hebrew)

·Big-5

·gb18030 (superset of gb2312)

·HZ-GB-2312

·Shift-JIS

·EUC-KR, EUC-JP, EUC-TW

·ISO-2022-JP, ISO-2022-KR, ISO-2022-CN

·KOI8-R

·x-mac-cyrillic

·IBM855 and IBM866

·X-ISO-10646-UCS-4-3412 and X-ISO-10646-UCS-4-2413 (unusual BOM)

·ASCII

Listing 1: Encodings supported by this import format

Empty lines (i.e. lines that only contain white space characters) are ignored.

Each non-comment and non-empty line is separated into cells by the user-defined column separator character (see table 2).

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).

Table 1: White space characters that are removed from the beginning or end of a string when a string is trimmed

Setting | Description
General
True value text | If the string in a cell that is treated as Boolean cell equals this text, the value in this cell is treated as Boolean True. All other strings will be treated as false. This comparison is done is case sensitive on the trimmed (see table 1) value of a cell.
Null value | If the string in a cell matches this string the Application Server will treat this cell as Null. This comparison is done is case sensitive.
Column separator | This specifies the character used in the source files to delimit columns. You can choose from a list of predefined characters.
Merge multiple separators | If this flag is not set one column separator character advices the Application Server to skip to the next column. If this flag is set, consecutive column separator characters will be treated as a single separator character.
Number of header lines | This defines the number of lines from in the beginning of the file that are treated as header lines and will therefore not be parsed.
Comment designator | If a line in the source file starts with this text, it is treated as comment line, i.e. it will not be parsed by the import.
Column mapping | This setting allows you to define the column mapping, i.e. the association of columns in the source file with specific properties of the feature or observation to be imported.
Localization Settings that are used to handle localized data.
Date time format | The pattern that is used to parse date time values given as string in the source files. See Date-time formatting for more information on date time patterns. Note that the Culture setting (see below) will also used for the interpretation of the date time pattern defined here.
Culture | The culture used for parsing date time values (see also above), numeric values etc.

Table 2: Import type specific settings

Column Mapping

The flexibility of this import type is mainly founded in the possibility to map columns in the source files to specific properties or other characteristics of the feature or observation to be imported. The column mapping is part of the import type's specific settings. The column mapping consists of some general settings (see table 3) and a series of column associations (table 4).

Setting

Description

Store source files

If enabled the source files that were imported with each import session created from this import definition, will be stored on the Application Server and linked to the import session. This option gives you the possibility to store the original data files along with your import session.

Default: false

Feature type

Defines the feature type of the data to be imported.

Container feature type

This import format supports the creation of container features and the mapping of features to these container features. This setting defines the feature type of container features to be created.

Feature name resolving

With this import type you have different possibilities how the import shall detect the name of the feature for which data is imported.

·Fixed feature: Import data for a fixed (see below) feature.

·Read from file name: Read feature name from (a part of) the file name. You can use a regular expression to filter out the part of the file name that defines the feature name.

·Read from column: Read feature name from a specific column of the source file. If set to this option you will have to define a column mapping for the feature name.

Feature

This setting is only available if the Feature name resolving is set to Fixed feature.

Defines the feature for which data shall be imported.

Container Feature

This setting is only available if the Feature name resolving is set to Fixed feature.

Defines the container feature for which data shall be imported.

Regular expression for feature name

This setting is only available if the Feature name resolving is set to Read from file name.

Here you specify a regular expression that is used to define the part of the file name that specifies the feature name. The actual feature name will be the match for the first sub-expression of that regular repression.

Example:

Original file name: AB_123-4.csv

Regular expression: AB_([0-9]{3}-[0-9])\.csv

Resulting feature name: 123-4

Regular expression for container feature name

This setting is only available if the Feature name resolving is set to Read from file name. See above for a description how to use regular expressions for defining the feature name.

Spatial system of feature

Defines the type of spatial system to use for newly created features.

Spatial System of container feature

Defines the type of spatial system to use for newly created container features.

Axis reference system

Only available if Spatial system of feature is set to Axis reference.

Defines the axis reference that shall be used with newly created features.

Table 3: General settings for the column mapping

Setting

Description

Column index in file

This is the 1-based (meaning first column as index 1) index of the column(s) that is/are mapped to a single property or characteristic of a feature ore observation.

User can define a single column index or a range or collection of column indices that will be read from the source file and written to a property that is mapped. Multiple columns can simply be defined by specifying a comma separated list of column indices, or column ranges.

Examples:

·1-3, 5 will map column 1, 2, 3 and 5

·7-9 or will map column 7, 8, 9

·1, 2, 3, 4, 7-9 will map column 1, 2, 3, 4, 7, 8, 9

Multiple column indices will only be respected if you choose Join Columns with delimiter as pre-processing type (see below). If not only the first index will be mapped.

Pre-processing type.

You can select a pre-processing step that is performed before the source string is treated as value. Following pre-processing types are available:

·None: No pre-processing will be performed

·Join Column with delimiters: Multiple columns in the source file are concatenated using the specified delimiter.

Example:

·Input file has following data:
axis; point_id; datetime; value
*KW23*; *4*; 2015-07-23 09:34; -32,43

·Expected output is
name: *KW23-4*
date: 2015-07-23 09:34
value: -32,43

·Then user can configure the import like so:
Column index: 1,2
Preprocessing type: Join columns with delimiter

Post-processing type

Post processing takes the result of the pre-processing as input and processes the text accordingly. If there is no pre-processing then it simply takes the content of a single column.

Post processing takes place after pre-processing, the output of the post processing is then mapped to the property of the feature.

·None: No post processing is performed.

·Split and take word: Split the value with given split character and take the word at given (1 based) index .
Needs two settings: Split character(the character[s] that will be used to split the text and Word number to take(which word to take after split). Example: if input text is 'KW23-4', user wants to extract the "KW23" and map to a property then the post processing definition should be: Split characters: -, Word number to take: 1.

·Skip from beginning and end: Defines how many characters to be ignored from the beginning and from the end of the input text. This processor has two settings: Characters to skip at the beginning and characters to skip at the end. Example: the post processor gets an text: "abc4957xyz" as input. User wants to extract the numeric part of the text i.e. 4957 and map to a column. The post processing settings will be: Characters to skip at the beginning: 3, Characters to skip at the end: 3. Output is: 4957

Property unit

If a mapping is done for a property of property type quantity. you have to choose the unit of the values in the source file.

All imported values will be interpreted as values in this unit.

Table 4: Settings for each mapped column

Container relationship import

This import type also supports container relationships. It is possible to select name of a container feature as one of the columns. In this case all features created during import will be linked to a container feature, whose name is defined in the corresponding row. It is also possible to specify the spatial system tyoe and spatial reference system of container features. Non-existent container features will be created.


Generic (simple)

Last edited: 12/11/2017 11:35:14 AM

This import format is a generic format that can be used to import features and observations data for all feature types.

Table 1 shows which data can be imported with this import type. The import type can create features that are not currently present in the domain to which the import is targeted. Existing features will not be changed in any way.

Data

Notes

Feature Name

New features can be created automatically, observations for already existing features will be appended to that feature.

Feature subtype

Newly created features can be imported with the right feature subtype (if provided by the import file)

Subtype for existing features will not be changed.

If the source file contains conflicting subtypes for the same feature (in different lines) the first defined subtype will be used.

Observation base data

Sampling Timestamp

Result timestamp

Erroneous flag

Type specific observation data

All data for properties on level 0 of the property structure the type specific observation data

Table 1: Data that can be imported by the generic text import type

The file format expected by generic import type is a text file structured in lines and columns. The text file can include Unicode characters encoded as UTF-8 (which is backward compatible to ANSI with codepage 65001). The file may use a BOM (Unicode byte order mark) to specify the byte order of the character encoding.

A line in the source file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Leading and trailing white space characters (see table 2) will be automatically trimmed from each line. If the column separator is set to tab (U+0009) tabs will not be trimmed. The first character of a line is defined as the first non-white space character, the last character as the last not white space character.

Lines where the first character is a # (U+0023, UTF-8: 0x23) are treated as comment lines and will be ignored. If the # is contained in a line but not the first character in the line it will be treated as data. Empty lines (after trimming) except the first non-comment line after the first header line are ignored.

Each non-comment and non-empty line is separated into cells by the column separator character. The column delimiter character can be set in the import type's settings. Only one column delimiter character is allowed between two columns, i.e. for n columns you need exactly n-1 column delimiters, and column n is the column after the n-1th column delimiter.

The first two non-comment and non-empty lines are treated as header lines. Header lines contain processing information for the import. The first header line is used to define the contents of a column by specifying a column content identifier in each cell. This column content identifier is used by the Application Server to match the data in that column to some characteristic of the feature or observation. Columns with a column content identifier that is not recognized by the Application Server are ignored. The second header line is used to define the unit for numeric values if these numeric values are matched against a quantity property in the observation's type specific data property structure.

Since the column headers in header line 1 define the contents of each column, the sequence of columns is not important, however all mandatory columns need to be present. The Generic text import type defines some columns that can or must be present in every source file (see table 3). The identifiers of the properties in the type specific data property structure of the observation for the feature type that is imported are used as column content identifiers for additional feature type specific columns. See the documentation of the feature types for more information.

The data in the columns (after the header lines) can be of type numeric (and quantity), text, date & time and boolean. Table 3

Figure 1: Example for an import source file used to import distance observations

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).

Table 2: White space characters

Column header identifier | Mandatory |
FEATURE |  | Name of the feature or Alias name (if an alias scheme is used)
FEATURE_SUBTYPE |  | Name of the feature subtype Default: null
OBSERVATION_SAMPLINGTIMESTAMP |  | Sampling timestamp of the observation. Must be a unique sampling timestamp.
ERRONEOUS |  | Specifies if the observation is erroneous Default: false

Table 3: Common columns for the generic text import format

Setting | Description
String | Any unicode string. The column separator is not allowed within the string.
URI | Any URI. The column separator is not allowed within the string.
Quantity | A numeric value that is read as quantity. The number must not contain grouping characters. The unit is deriver from the second header line.
Numeric | A numeric value that is read as quantity. The number must not contain grouping characters.
Boolean | A three valued Boolean value (true, false, null). The strings yes, true and 1 are interpreted as true (case insensitive), everything else is interpreted as false (except the null value string which is of course interpreted as null)
Date time | A date time offset value that conforms to the date time format string and date time culture given in the general import settings.

Table 4: Supported data types with the generic import type.

Setting | Description
General
Feature type | The feature type for which the data shall be imported
Null value | The string that identifies a null value. If a cell contains a string that equals this null value string the value will be interpreted as null. If left empty empty cells will be interpreted as null. If set to a non-empty value and a cell contains an empty value this will result in an error.
Column separator | The column separator to be used
Store source files | If enabled the source files that were imported with each import session created from this import definition, will be stored on the Application Server and linked to the import session. This option gives you the possibility to store the original data files along with your import session. Default: false
Spatial location
Spatial system | Defines the spatial system to use for features created by the import.
Axis reference system | Defines the axis reference system to be used for newly created features. Only used if Spatial System is set to Axis.
Coordinate system | Defines which coordinate system is used with newly created features. Only used if Spatial System is set to Coordinate system
Date time format | The format used to parse date time offset values. The Date time format is always based on the selected culture (see below). For more details on date time formats see chapter Date & time formatting
Date time culture | The culture used to parse date time offset values. Specifics of each of the selectable cultures can be found in the

Table 5: Settings of the import type generic text


%Text%

Navigation: »No topics above this level«

GVR

Last edited: 12/11/2017 11:35:14 AM

GVR is a text based file format for transferring water table data originating from a software product called Autograph. The GVR format has changed over the years and there is no official documentation on the exact syntax of GVR. Therefore it is hardly possible to provide a GVR parser that will support all kinds of GVR files out there; however Redbex is able to parse a wide range of differently formatted GVR files. Below you find a description of the GVR file format as understood by Redbex.

Each GVR files contains data for one Redbex feature. The GVR import therefore will create or update one feature of type Ground water level for each GVR file. Details about what data is parsed and stored during can be found below.

Note: During import some of the values found in the GVR source files have to be translated to Redbex classification elements. It is therefore mandatory for this import that in the domain where the GVR files are imported used classifications are defined for classification types Aquifer type, Drill hole type and Standard comment.

The Import type specific settings are shown in table 1.

Setting

Description

Store source files

If enabled the source files that were imported with each import session created from this import definition, will be stored on the Application Server and linked to the import session. This option gives you the possibility to store the original data files along with your import session.

Default: false

Coordinate system

Mandatory.

GVR files can contain spatial information (Easting, Northing) about the location of the ground water level. For correct interpretation of these values the user must select a coordinate system. The GVR import supports only projected coordinate systems.

All newly created features will be set to this coordinate system.

Value type

Can be either Relative or Absolute. If Relative is chosen Redbex will convert the data in the source files to absolute values using the values of inclination and pipe top edge found in the source file.

Create classification elements

If set the import will try to create missing classification elements in used classifications for classification types Aquifer type, Drill hole type and Standard comment.

Note that the user executing the import has to have the permission to modify classification elements of these classifications for this setting to have effect.

Table 1: Import type specific settings

Physical structure of GVR files

GVR files are text files that can be in different encodings, Redbex supports UTF-8, UTF-16 or UTF-32, ASCII (7 bit), ANSI, for ANSI encoding Redbex will try to guess the code page. The file may use a BOM (Unicode byte order mark) to specify the byte order of the character encoding.

A line in the GVR file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

The file stem (= file name without extension) of a GVR file defines the ID (or name) of the ground water measurement point. The extension of the file is not relevant in Redbex but is usually GVR.

All numeric values in the GVR files use the point as decimal separator.

Logical structure of GVR files

GVR files consist of two parts: The mandatory header and the optional data part.

The first nine lines in the GVR file are interpreted by Redbex as the header lines. Each of these lines consists of one or more cells separated from each other by one or more spaces (SPACE, U+0020, UTF-8: 0x20). The exact meaning of each line and each cell in those lines is shown in Table 1.

All lines following the ninth nine header lines to the first line containing only the * character (ASTERISK, U+002A, UTF-8: 0x2A) are interpreted as comment lines and will not be used by Redbex in any way. The line with the single * character, terminates the header.

Line | Cell | Meaning
1 | 1 | Numerical value. Optional. Default is null. Defines Northing of the ground water measurement point. Northing and Easting and Elevation (see below) are used by Redbex to locate the measurement point. The values of Northing and Easting are interpreted in the Coordinate system the user has chosen in the import format settings.
2 | 1 | Numerical value. Optional. Default is null. Defines Easting of the ground water measurement point.
3 | 1 | Numerical value. Default is null. Terrain elevation at the ground water measurement point.
4 |  | Numerical value. Optional. Together Section and Distance (see below) provide an alternative way of defining the ground water measurement point location. Redbex does not use this information.
5 | 1 | Numerical value. Optional. Distance. Not used by Redbex (see above)
6 | 1 | Alphanumeric value. Mandatory. Type of the drilling (e.g. classified by casing. The type of drilling can be any alphanumeric string (without spaces). In Redbex this string ins translated into a classification element by case insensitive comparison of the string in the GVR file with the code of the classification elements of the used Drilling Type classification.
 | 2 | Alphanumeric value. Mandatory. Defines if the GVR file contains exact points in time or just dates for each reading. A value of -1 or a Ja (case insensitive) indicates that the data part has time values. Any other alphanumeric value indicates that the data part has no time values.
 | 3 | Alphanumeric value. Optional. Not used by Redbex
7 7 | 1 | Numeric value. Mandatory. Elevation of top edge of pipe (= Reference elevation if data is interpreted as depth values). Use -999 if top edge is unknown. Note that in that case depth values cannot be converted to absolute values. Values less than -100 or greater than 10000 are invalid.
 | 2 | Numeric value. Optional (Default value 0). Bearing of the drilling given in compass degrees. If the drilling is not a perpendicular drilling this cell gives the direction of the drilling. For a perpendicular drilling the value of this cell shall be 0. Values < 0 or greater 360 will be normalized to a range in [0, 360]
8 | 1 | Numeric value. Mandatory. Final depth of the drilling expressed as elevation. Use -999 if final depth elevation is unknown Values less than -100 or greater than 10000 are invalid.
 | 2 | Numeric value. Optional. Default is 90 Inclination of the drilling given in degrees. 90 is perpendicular down, -90 is perpendicular up. Values less than -90 or greater than 90 are invalid.
9 | 1 | Numeric value. Mandatory. Default is null Filter length must be greater than 0. Use -999 if filter length is not known or not applicable.
 | 2 | Numeric value. Mandatory. Average value of measurements. Not used by Redbex.
 | 3 | Alphanumeric value. Optional. Default is empty Type of aquifer (classified by its geological characteristics). The type of aquifer can be any alphanumeric string (without spaces). In Redbex this string ins translated into a classification element by case insensitive comparison o f the string in the GVR file with the code of the classification elements of the used Aquifer Type classification.

Table 2: Description of header lines and cells in the GVR file format

All lines after the line with a single * terminating the header are interpreted as data lines. Empty lines are ignored. The first line with a single * after the start of the data part is terminating the data block and the GVR file. Any data after that line is ignored. If no such line is found for the data part Redbex will read all data till the end of the file.

The contents of a data line is again organized in cells. The first 5 cells are mandatory (have to be present in any GVR file) and are separated by one or more spaces. Table 2 describes the meaing of these 5 cells.

Cell No | Description
1 | Numeric value. Mandatory. Year when measurement was taken
2 | Numeric value. Mandatory. Month when measurement was taken
3 | Numeric value. Mandatory. Day when measurement was taken
4 | Numeric value. Mandatory. Measured value. This value is interpreted either as depth or as absolute elevation. Depending on the import format settings. Use -999 to express null.
5 | Alphanumeric value. Mandatory. Correctness of measurement. J is interpreted as correct all other values are interpreted as incorrect. In Redbex an incorrect measurement is stored as erroneous observation.

Table 3: Description of the first 5 cells cells in a data GVR line

If the header of the GVR file specifies that the file contains time the last 8 characters of the line are interpreted as time (format hh:mm:ss).

The data between the 5th cell and the time (or the end of line if no time is given) is interpreted as standard command and free comment. The standard comment is a comment that is interpreted by Redbex by matching that string against the Standard Comment Classification. If a (non-empty) free comment is found that comment will be added as observation comment in the observation's associated data. The standard comment is separated from the free comment by a single space. Maximum length of the standard comment is 25 characters.


Inclinometer

Last edited: 12/11/2017 11:35:14 AM

The inclinometer import type can be used to import data for the feature type Inclinometer.

Data | Notes
Feature Name | New features can be created automatically, observations for already existing features will be appended to that feature.
Type specific observation data | Depth, deviation in A, deviation in B, Zero-reading and Erroneous flag

Table 1: Data that can be imported by this import type

The file format expected by this import type is a text file structured in lines and columns. The text file can include Unicode characters encoded as UTF-8 (which is backward compatible to ANSI with codepage 65001). The file may use a BOM (Unicode byte order mark) to specify the byte order of the character encoding.

A line in the source file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Leading and trailing white space characters (see table 2) will be automatically trimmed from each line. If the column separator is set to tab (U+0009) tabs will not be trimmed. The first character of a line is defined as the first non-white space character, the last character as the last not white space character.

Lines where the first character is a # (U+0023, UTF-8: 0x23) are treated as comment lines and will be ignored. If the # is contained in a line but not the first character in the line it will be treated as data. Empty lines (after trimming) except the first non-comment line after the first header line are ignored.

Each non-comment and non-empty line is separated into cells by the column delimiter character. The column delimiter character can be set in the import type's settings. Only one column delimiter character is allowed between two columns, i.e. for n columns you need exactly n-1 column delimiters, and column n is the column after the n-1th column delimiter.

The first two non-comment and non-empty lines are treated as header lines. Header lines contain processing information for the import. The first header line is used to define the contents of each column by specifying a column content identifier in each cell. This column content identifier is used by the Application Server to match the data in that column to some characteristic of the inclinometer feature or observation. Columns with a column content identifier that is not recognized by the Application Server are ignored. The second header line is used to define the unit for numeric values if these numeric values are matched against a quantity property in the observation's type specific data property structure.

Table 2 shows the column content identifiers that must be present for this import type. Since the column headers in header line 1 define the contents of each column, the sequence of columns is not important

Column content identifier | Description
FEATURE | Identifying name of the inclinometer feature
OBSERVATION_SAMPLINGTIMESTAMP | Sampling timestamp of the observation
DEPTH | Depth of the observed value
A | Deviation in A
B | Deviation in B
ZEROREADING | Zero reading flag
ERRONEOUS | Erroneous flag

Table 2 column content identifiers that must be present for this import type

Figure 1: Example for an import source file used to import inclinometer data. Note the orange arrows show tabs.


%Text%

Navigation: »No topics above this level«

Interlab (Version 4)

Last edited: 12/11/2017 11:35:14 AM

Interlab is a file format for the transfer of analytical data between database systems, e.g. from water and food laboratories to other database systems. The initiative for the creation of file format was taken by the then Swedish Water and Waste Water Association, VAV (now Swedish Water) in the early 1990s. The first version was published in 1995. Redbex Supports Interlab version 4.0.

For a full documentation of the Interlab standard please refer to the original Interlab specification. This chapter discusses aspects of the Interlab that are relevant for understanding how Redbex will import data from Interlab files.

Syntactical aspects

File name

The Interlab Standard specifies that .lab is the only valid extension for Interlab files. Redbex however does not check the extension for Interlab files but inspects the file contents to check if the file is an Interlab file.

Text encoding

According to the Interlab standard Interlab files can be encoded using UTF-8, UTF-16 or UTF-32. The actual encoding used may optionally be specified in the header of Interlab files using the #Tecken control sequence. Redbex will not use this information in from the header of the Interlab files but will detect the actually used encoding by inspecting Interlab files on a byte level. This approach is more reliable since the actual encoding of a file might easily change while the header of the Interlab file is probably not changed accordingly.

Redbex supports Interlab files in UTF-8 (with or without BOM), UTF-16 or UTF-32 encoding (both little-endian and big-endian).

Line

While not specified in the Interlab standard Redbex defines a line in an Interlab file as a sequence of characters followed by a line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Trimming lines

When reading Interlab files Redbex will ignore leading and trailing white space characters of each line in the file. White space characters are defined as shown in table 1.

Empty lines

When reading Interlab files Redbex will always skip any empty lines or lines that contain only white space characters (see table 1).

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).

Table 1: White space characters

Comment lines

The Interlab standard does not specify a possibility to add comments to an Interlab file. Deviating from the standard Redbex will interpret every line starting with a $ character as a comment line, and will therefore not parse this line.

Control sequences

Interlab files contain control sequences that advice the reading software product on how to read and interpret the data in the Interlab file. Control sequences always start with a # character followed by a sequence of characters. Control sequences are case insensitive.

Header

An Interlab file always contains a header. The header is a series of control sequences starting with the #interlab control sequence and ending at the first #provadm control sequence.

Data section

A data section consists of a provadm section and a provdat section. A valid data section must always have a provadm and a provdat section, one Interlab file may have multiple data sections. each provadm and provdat section contains one header line, and one or more data lines.

Each line is a sequence of semicolon separated cells of data. According to the Interlab standard the last data cell must also be terminated by a semicolon. Redbex will determine if the last cell is terminated by a semicolon by inspecting the first data line in the first provadm section of the file.

The first line in a provdat or provadm section is the header line, all following lines are data lines. The header line specifies which kind of data is to be found in the cells of the following lines. The type of data is specified in header lines by using strings that are defined in the Interlab standard. Redbex compares these strings case insensitive.

The number of data cells in the header line must match the number of data cells in each data line.

A provadm section starts with the #provadm control sequence a provdat section starts with the #provdat control sequence. The provadm section ends with the #provdat control sequence. The provdat section ends with the #provadm section of the next data section or with the #slut control sequence.

Semantic aspects

Feature name

Interlab uses the Lablittera cell to give each sample a unique id, however multiple samples may belong to the same Redbex feature, this association of sample IDs to features is not defined in the Interlab format. To still be able to import data from Interlab to Redbex, Redbex therefore uses the Specific provplats cell. This cell is optional according to the Interlab standard but Redbex defines it a mandatory and each line in provadm sections must have a non empty Specific provplats cell.

Null

Empty cells are considered as null. Cells containing only a single dash - are also considered as null cells.

Mapping of sample types to feature types

The data in Interlab formats is imported into features of different types according to the value of the provtyp cell in the provadm section setting. Table 1 shows the mapping of provtyp to feature types that is used by the import. The import settings allow you to add additional provtyp identifiers for each supported feature type.

Provtyp | Feature type
Avloppsvatten Dricksvatten Grundvatten Ytvatten Dagvatten/dräneringsvatten Lakvatten Länshållningsvatten Processvatten Spolvatten Släckvatten Tunnelavloppsvatten | Water analysis
Sediment Slam Jord Bergkross Asfalt Betong Sulfidjord Industri och gruvslagg | Soil analysis
Porgas Övrig luft | Air Analysis

Table 2: Mapping of provtypes to feature types

Import settings

Setting | Description
Coordinate system | Interlab files do not contain spatial information, however this setting can be used to create new features with the right spatial reference system
Create classification elements | If set the import will try to create missing classification elements. Note that this is only possible if the user executing the import has appropriate permissions and if a classification is set as

Table 3: Settings of the import type Interlab


Landmäteriet (Blocks/Lots/Buildings)

Navigation: »No topics above this level«

Lantmäteriet (Areas / Lots / Buildings)

Last edited: 12/11/2017 11:35:14 AM

This import type reads areas, lots and buildings from a GSD-Property Map database of the Swedish Lantmäteriet Organization and transforms them to features of type Landregister Area, <%TARGETTITLE%>, %Text% features. The features will be related to each other using platform relations according to the information found in the source database.

Additionally to creating new features an updating existing features, this import type will also modify features in Redbex that are not found in the GSD database. On those features the import will set the Obsolete property in the type specific data of the feature.

The import is always performed with a geographic filter, i.e. only those objects in the GSD-Property Map database will be handled by the import that fall within the provided filter-geometry and only those features in Redbex will be compared that fall within the provided filter-geometry.

Table 2 shows how the terms used in Lantmäteriet are translated to English in Redbex.

Setting

Description

General

Coordinate system

Mandatory

The coordinate system that is expected in the source database. Lantmäteriet uses EPSG 3006 as default. So you should have a matching projected coordinate system set up and select this coordinate system here.

Import region

Mandatory

Defines the region that defines which data will be imported from the GSD-Property map database and the import features in Redbex that will be used for matching during import

Block creation strategy

Defines how the importer shall form areas out of the provided lots.

Alias scheme for old building names

Mandatory

The old names of buildings that the importer renamed because the building could be matched by geometry will be kept as an alias in this scheme.

Advanced settings

Create classification elements

If set, the import will try to create missing classification element. Elements can only be created if the importing user has the appropriate permissions.

Geometry match for buildings

If set, the matching of buildings found in the GSD-Property Map database to already existing features of type TMO building will be done by name and - if no name match is found - by geometry. In this case a feature is a match if it's geometry matches more than 90% (i.e. if the Area of the intersection of the geometries is more than 90% of the area of the geometry in the GSD database).

This option only needs to be turned on if there are already features of type TMO building in Redbex that were imported from another source or created manually.

Table 1: Type specific import settings in group General for this import type.

English term | Swedish term
Lot | Fastighet
Block | Block
Area | Kvarter
Building | Byggnad
District | Trakt
Commnity | Kommun
State | Län

Table 2: Translation of terms used in the Lantmäteriet import


TMO

Last edited: 12/11/2017 11:35:16 AM

TMO is a database system developed by Trafikverket. TMO is used to store data of various types amont them ground water data, surveying data and environmental data.

Note: The Redbex TMO import is implemented as a one-time-only import. I.e. the import is meant to be used to convert data from TMO databases to Redbex but not for regular updates of data from TMO to Redbex.

There are two slightly different version of TMO that are both supported by Redbex: Hasp and Regular Before importing the user has to define the dialect. The import procedure will then parse the data according to the selected dialect.

Preparing the TMO database

This only applies to TMO databases of dialect regular

Redbex imports data from TMO databases by directly connecting to these databases. However TMO systems use a second independent database for Geographic data. To make this data available to the TMO import you must fist create a view in the TMO database (typically called WebDB) that creates a bridge to the geographic data.

Listing 1 shows the SQL command to create this view. Note that you have to change the script in order to match your database name

CREATE VIEW ByggnadSpatial
AS
SELECT [OBJECTID_1]
,[OBJECTID]
,[X_Centroid]
,[Y_Centroid]
,[Name]
,[ByggnadID]
,[area]
,[len]
,[SHAPE]
FROM [<Name Of Tmo GeoDB>].[dbo].[SBK_BYGGNADER]

Listing 1: Script for creating the ByggnadSpatial view


3D Movement in Tunnel

Last edited: 11/8/2017 10:15:02 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


%Text%

Navigation: »No topics above this level«

Generic (customizable)

Last edited: 11/8/2017 10:15:02 AM

This import format is a generic format that can be used to import features and observations data for all feature types. It can read data from a wide range of tabular-structured data files, by allowing you to define which column in the source file contains what information as well as many other settings. This import type gives you great flexibility to adapt to the structure of a given source file.

The file format expected by generic import type is a text file structured in lines and columns. The import type will try to detect the encoding of the source files automatically. Following encodings are supported:

·UTF-8

·UTF-16 (BE and LE)

·UTF-32 (BE and LE)

·windows-1252 (mostly equivalent to iso8859-1)

·windows-1251 and ISO-8859-5 (cyrillic)

·windows-1253 and ISO-8859-7 (greek)

·windows-1255 (logical hebrew. Includes ISO-8859-8-I and most of x-mac-hebrew)

·ISO-8859-8 (visual hebrew)

·Big-5

·gb18030 (superset of gb2312)

·HZ-GB-2312

·Shift-JIS

·EUC-KR, EUC-JP, EUC-TW

·ISO-2022-JP, ISO-2022-KR, ISO-2022-CN

·KOI8-R

·x-mac-cyrillic

·IBM855 and IBM866

·X-ISO-10646-UCS-4-3412 and X-ISO-10646-UCS-4-2413 (unusual BOM)

·ASCII

A line in the source file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Leading and trailing white space characters (see table 1) will be automatically trimmed from each line. If the column separator is set to tab (U+0009) tabs will not be trimmed. The first character of a line is defined as the first non-white space character, the last character as the last non-white space character.

Lines where the first characters equals the user-defined Comment Designator (see table 2) are treated as comment lines and will be ignored. If a comment designator is contained in a line, but is not the first character in the line it will be treated as data.

Empty lines (i.e. lines that only contain white space characters) are ignored.

Each non-comment and non-empty line is separated into cells by the user-defined column separator character (see table 2).

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).

Table 1: White space characters that are removed from the beginning or end of a string when a string is trimmed

Setting | Description
True value text | If the string in a cell that is treated as Boolean cell equals this text, the value in this cell is treated as Boolean True. All other strings will be treated as false. This comparison is done is case sensitive on the trimmed (see table 1) value of a cell.
Null value | If the string in a cell matches this string the Application Server will treat this cell as Null. This comparison is done is case sensitive.
Column separator | This specifies the character used in the source files to delimit columns. You can choose from a list of predefined characters.
Merge multiple separators | If this flag is not set one column separator character advices the Application Server to skip to the next column. If this flag is set, consecutive column separator characters will be treated as a single separator character.
Number of header lines | This defines the number of lines from in the beginning of the file that are treated as header lines and will therefore not be parsed.
Comment designator | If a line in the source file starts with this text, it is treated as comment line, i.e. it will not be parsed by the import.
Column mapping | This setting allows you to define the column mapping, i.e. the association of columns in the source file with specific properties of the feature or observation to be imported.

Table 2: Import type specific settings

Column Mapping

The flexibility of this import type is mainly founded in the possibility to map columns in the source files to specific properties or other characteristics of the feature or observation to be imported. The column mapping is part of the import type's specific settings. The column mapping consists of some general settings (see table 3) and a series of column associations (table 4).

Setting

Description

Store source files

If enabled the source files that were imported with each import session created from this import definition, will be stored on the Application Server and linked to the import session. This option gives you the possibility to store the original data files along with your import session.

Default: false

Feature type

Defines the feature type of the data to be imported.

Container feature type

This import format supports the creation of container features and the mapping of features to these container features. This setting defines the feature type of container features to be created.

Feature name resolving

With this import type you have different possibilities how the import shall detect the name of the feature for which data is imported.

·Fixed feature: Import data for a fixed (see below) feature.

·Read from file name: Read feature name from (a part of) the file name. You can use a regular expression to filter out the part of the file name that defines the feature name.

·Read from column: Read feature name from a specific column of the source file. If set to this option you will have to define a column mapping for the feature name.

Feature

This setting is only available if the Feature name resolving is set to Fixed feature.

Defines the feature for which data shall be imported.

Container Feature

This setting is only available if the Feature name resolving is set to Fixed feature.

Defines the container feature for which data shall be imported.

Regular expression for feature name

This setting is only available if the Feature name resolving is set to Read from file name.

Here you specify a regular expression that is used to define the part of the file name that specifies the feature name. The actual feature name will be the match for the first sub-expression of that regular repression.

Example:

Original file name: AB_123-4.csv

Regular expression: AB_([0-9]{3}-[0-9])\.csv

Resulting feature name: 123-4

Regular expression for container feature name

This setting is only available if the Feature name resolving is set to Read from file name. See above for a description how to use regular expressions for defining the feature name.

Spatial system of feature

Defines the type of spatial system to use for newly created features.

Spatial System of container feature

Defines the type of spatial system to use for newly created container features.

Axis reference system

Only available if Spatial system of feature is set to Axis reference.

Defines the axis reference that shall be used with newly created features.

Table 3: General settings for the column mapping

Setting

Description

Column index in file

This is the 1-based (meaning first column as index 1) index of the column(s) that is/are mapped to a single property or characteristic of a feature ore observation.

User can define a single column index or a range or collection of column indices that will be read from the source file and written to a property that is mapped. Multiple columns can simply be defined by specifying a comma separated list of column indices, or column ranges.

Examples:

·1-3, 5 will map column 1, 2, 3 and 5

·7-9 or will map column 7, 8, 9

·1, 2, 3, 4, 7-9 will map column 1, 2, 3, 4, 7, 8, 9

Multiple column indices will only be respected if you choose Join Columns with delimiter as pre-processing type (see below). If not only the first index will be mapped.

Pre-processing type.

You can select a pre-processing step that is performed before the source string is treated as value. Following pre-processing types are available:

·None: No pre-processing will be performed

·Join Column with delimiters: Multiple columns in the source file are concatenated using the specified delimiter.

Example:

·Input file has following data:
axis; point_id; datetime; value
*KW23*; *4*; 2015-07-23 09:34; -32,43

·Expected output is
name: *KW23-4*
date: 2015-07-23 09:34
value: -32,43

·Then user can configure the import like so:
Column index: 1,2
Preprocessing type: Join columns with delimiter

Post-processing type

Post processing takes the result of the pre-processing as input and processes the text accordingly. If there is no pre-processing then it simply takes the content of a single column.

Post processing takes place after pre-processing, the output of the post processing is then mapped to the property of the feature.

·None: No post processing is performed.

·Split and take word: Split the value with given split character and take the word at given (1 based) index .
Needs two settings: Split character(the character[s] that will be used to split the text and Word number to take(which word to take after split). Example: if input text is 'KW23-4', user wants to extract the "KW23" and map to a property then the post processing definition should be: Split characters: -, Word number to take: 1.

·Skip from beginning and end: Defines how many characters to be ignored from the beginning and from the end of the input text. This processor has two settings: Characters to skip at the beginning and characters to skip at the end. Example: the post processor gets an text: "abc4957xyz" as input. User wants to extract the numeric part of the text i.e. 4957 and map to a column. The post processing settings will be: Characters to skip at the beginning: 3, Characters to skip at the end: 3. Output is: 4957

Property unit

If a mapping is done for a property of property type quantity. you have to choose the unit of the values in the source file.

All imported values will be interpreted as values in this unit.

Table 4: Settings for each mapped column

Container relationship import

This import type also supports container relationships. It is possible to select name of a container feature as one of the columns. In this case all features created during import will be linked to a container feature, whose name is defined in the corresponding row. It is also possible to specify the spatial system tyoe and spatial reference system of container features. Non-existent container features will be created.


Generic (simple)

Last edited: 11/8/2017 10:15:02 AM

This import format is a generic format that can be used to import features and observations data for all feature types.

Table 1 shows which data can be imported with this import type. The import type can create features that are not currently present in the domain to which the import is targeted. Existing features will not be changed in any way.

Data

Notes

Feature Name

New features can be created automatically, observations for already existing features will be appended to that feature.

Feature subtype

Newly created features can be imported with the right feature subtype (if provided by the import file)

Subtype for existing features will not be changed.

If the source file contains conflicting subtypes for the same feature (in different lines) the first defined subtype will be used.

Observation base data

Sampling Timestamp

Result timestamp

Erroneous flag

Type specific observation data

All data for properties on level 0 of the property structure the type specific observation data

Table 1: Data that can be imported by the generic text import type

The file format expected by generic import type is a text file structured in lines and columns. The text file can include Unicode characters encoded as UTF-8 (which is backward compatible to ANSI with codepage 65001). The file may use a BOM (Unicode byte order mark) to specify the byte order of the character encoding.

A line in the source file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Leading and trailing white space characters (see table 2) will be automatically trimmed from each line. If the column separator is set to tab (U+0009) tabs will not be trimmed. The first character of a line is defined as the first non-white space character, the last character as the last not white space character.

Lines where the first character is a # (U+0023, UTF-8: 0x23) are treated as comment lines and will be ignored. If the # is contained in a line but not the first character in the line it will be treated as data. Empty lines (after trimming) except the first non-comment line after the first header line are ignored.

Each non-comment and non-empty line is separated into cells by the column separator character. The column delimiter character can be set in the import type's settings. Only one column delimiter character is allowed between two columns, i.e. for n columns you need exactly n-1 column delimiters, and column n is the column after the n-1th column delimiter.

The first two non-comment and non-empty lines are treated as header lines. Header lines contain processing information for the import. The first header line is used to define the contents of a column by specifying a column content identifier in each cell. This column content identifier is used by the Application Server to match the data in that column to some characteristic of the feature or observation. Columns with a column content identifier that is not recognized by the Application Server are ignored. The second header line is used to define the unit for numeric values if these numeric values are matched against a quantity property in the observation's type specific data property structure.

Since the column headers in header line 1 define the contents of each column, the sequence of columns is not important, however all mandatory columns need to be present. The Generic text import type defines some columns that can or must be present in every source file (see table 3). The identifiers of the properties in the type specific data property structure of the observation for the feature type that is imported are used as column content identifiers for additional feature type specific columns. See the documentation of the feature types for more information.

The data in the columns (after the header lines) can be of type numeric (and quantity), text, date & time and boolean. Table 3

Figure 1: Example for an import source file used to import distance observations

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).

Table 2: White space characters

Column header identifier | Mandatory |
FEATURE |  | Name of the feature or Alias name (if an alias scheme is used)
FEATURE_SUBTYPE |  | Name of the feature subtype Default: null
OBSERVATION_SAMPLINGTIMESTAMP |  | Sampling timestamp of the observation. Must be a unique sampling timestamp.
ERRONEOUS |  | Specifies if the observation is erroneous Default: false

Table 3: Common columns for the generic text import format

Setting | Description
String | Any unicode string. The column separator is not allowed within the string.
URI | Any URI. The column separator is not allowed within the string.
Quantity | A numeric value that is read as quantity. The number must not contain grouping characters. The unit is deriver from the second header line.
Numeric | A numeric value that is read as quantity. The number must not contain grouping characters.
Boolean | A three valued Boolean value (true, false, null). The strings yes, true and 1 are interpreted as true (case insensitive), everything else is interpreted as false (except the null value string which is of course interpreted as null)
Date time | A date time offset value that conforms to the date time format string and date time culture given in the general import settings.

Table 4: Supported data types with the generic import type.

Setting | Description
General
Feature type | The feature type for which the data shall be imported
Null value | The string that identifies a null value. If a cell contains a string that equals this null value string the value will be interpreted as null. If left empty empty cells will be interpreted as null. If set to a non-empty value and a cell contains an empty value this will result in an error.
Column separator | The column separator to be used
Store source files | If enabled the source files that were imported with each import session created from this import definition, will be stored on the Application Server and linked to the import session. This option gives you the possibility to store the original data files along with your import session. Default: false
Spatial location
Spatial system | Defines the spatial system to use for features created by the import.
Axis reference system | Defines the axis reference system to be used for newly created features. Only used if Spatial System is set to Axis.
Coordinate system | Defines which coordinate system is used with newly created features. Only used if Spatial System is set to Coordinate system
Date time format | The format used to parse date time offset values. The Date time format is always based on the selected culture (see below). For more details on date time formats see chapter Date & time formatting
Date time culture | The culture used to parse date time offset values. Specifics of each of the selectable cultures can be found in the

Table 5: Settings of the import type generic text


%Text%

Navigation: »No topics above this level«

GVR

Last edited: 11/8/2017 10:15:02 AM

GVR is a text based file format for transferring water table data originating from a software product called Autograph. The GVR format has changed over the years and there is no official documentation on the exact syntax of GVR. Therefore it is hardly possible to provide a GVR parser that will support all kinds of GVR files out there; however Redbex is able to parse a wide range of differently formatted GVR files. Below you find a description of the GVR file format as understood by Redbex.

Each GVR files contains data for one Redbex feature. The GVR import therefore will create or update one feature of type Ground water level for each GVR file. Details about what data is parsed and stored during can be found below.

Note: During import some of the values found in the GVR source files have to be translated to Redbex classification elements. It is therefore mandatory for this import that in the domain where the GVR files are imported used classifications are defined for classification types Aquifer type, Drill hole type and Standard comment.

The Import type specific settings are shown in table 1.

Setting

Description

Store source files

If enabled the source files that were imported with each import session created from this import definition, will be stored on the Application Server and linked to the import session. This option gives you the possibility to store the original data files along with your import session.

Default: false

Coordinate system

Mandatory.

GVR files can contain spatial information (Easting, Northing) about the location of the ground water level. For correct interpretation of these values the user must select a coordinate system. The GVR import supports only projected coordinate systems.

All newly created features will be set to this coordinate system.

Value type

Can be either Relative or Absolute. If Relative is chosen Redbex will convert the data in the source files to absolute values using the values of inclination and pipe top edge found in the source file.

Create classification elements

If set the import will try to create missing classification elements in used classifications for classification types Aquifer type, Drill hole type and Standard comment.

Note that the user executing the import has to have the permission to modify classification elements of these classifications for this setting to have effect.

Table 1: Import type specific settings

Physical structure of GVR files

GVR files are text files that can be in different encodings, Redbex supports UTF-8, UTF-16 or UTF-32, ASCII (7 bit), ANSI, for ANSI encoding Redbex will try to guess the code page. The file may use a BOM (Unicode byte order mark) to specify the byte order of the character encoding.

A line in the GVR file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

The file stem (= file name without extension) of a GVR file defines the ID (or name) of the ground water measurement point. The extension of the file is not relevant in Redbex but is usually GVR.

All numeric values in the GVR files use the point as decimal separator.

Logical structure of GVR files

GVR files consist of two parts: The mandatory header and the optional data part.

The first nine lines in the GVR file are interpreted by Redbex as the header lines. Each of these lines consists of one or more cells separated from each other by one or more spaces (SPACE, U+0020, UTF-8: 0x20). The exact meaning of each line and each cell in those lines is shown in Table 1.

All lines following the ninth nine header lines to the first line containing only the * character (ASTERISK, U+002A, UTF-8: 0x2A) are interpreted as comment lines and will not be used by Redbex in any way. The line with the single * character, terminates the header.

Line | Cell | Meaning
1 | 1 | Numerical value. Optional. Default is null. Defines Northing of the ground water measurement point. Northing and Easting and Elevation (see below) are used by Redbex to locate the measurement point. The values of Northing and Easting are interpreted in the Coordinate system the user has chosen in the import format settings.
2 | 1 | Numerical value. Optional. Default is null. Defines Easting of the ground water measurement point.
3 | 1 | Numerical value. Default is null. Terrain elevation at the ground water measurement point.
4 |  | Numerical value. Optional. Together Section and Distance (see below) provide an alternative way of defining the ground water measurement point location. Redbex does not use this information.
5 | 1 | Numerical value. Optional. Distance. Not used by Redbex (see above)
6 | 1 | Alphanumeric value. Mandatory. Type of the drilling (e.g. classified by casing. The type of drilling can be any alphanumeric string (without spaces). In Redbex this string ins translated into a classification element by case insensitive comparison of the string in the GVR file with the code of the classification elements of the used Drilling Type classification.
 | 2 | Alphanumeric value. Mandatory. Defines if the GVR file contains exact points in time or just dates for each reading. A value of -1 or a Ja (case insensitive) indicates that the data part has time values. Any other alphanumeric value indicates that the data part has no time values.
 | 3 | Alphanumeric value. Optional. Not used by Redbex
7 7 | 1 | Numeric value. Mandatory. Elevation of top edge of pipe (= Reference elevation if data is interpreted as depth values). Use -999 if top edge is unknown. Note that in that case depth values cannot be converted to absolute values. Values less than -100 or greater than 10000 are invalid.
 | 2 | Numeric value. Optional (Default value 0). Bearing of the drilling given in compass degrees. If the drilling is not a perpendicular drilling this cell gives the direction of the drilling. For a perpendicular drilling the value of this cell shall be 0. Values < 0 or greater 360 will be normalized to a range in [0, 360]
8 | 1 | Numeric value. Mandatory. Final depth of the drilling expressed as elevation. Use -999 if final depth elevation is unknown Values less than -100 or greater than 10000 are invalid.
 | 2 | Numeric value. Optional. Default is 90 Inclination of the drilling given in degrees. 90 is perpendicular down, -90 is perpendicular up. Values less than -90 or greater than 90 are invalid.
9 | 1 | Numeric value. Mandatory. Default is null Filter length must be greater than 0. Use -999 if filter length is not known or not applicable.
 | 2 | Numeric value. Mandatory. Average value of measurements. Not used by Redbex.
 | 3 | Alphanumeric value. Optional. Default is empty Type of aquifer (classified by its geological characteristics). The type of aquifer can be any alphanumeric string (without spaces). In Redbex this string ins translated into a classification element by case insensitive comparison o f the string in the GVR file with the code of the classification elements of the used Aquifer Type classification.

Table 2: Description of header lines and cells in the GVR file format

All lines after the line with a single * terminating the header are interpreted as data lines. Empty lines are ignored. The first line with a single * after the start of the data part is terminating the data block and the GVR file. Any data after that line is ignored. If no such line is found for the data part Redbex will read all data till the end of the file.

The contents of a data line is again organized in cells. The first 5 cells are mandatory (have to be present in any GVR file) and are separated by one or more spaces. Table 2 describes the meaing of these 5 cells.

Cell No | Description
1 | Numeric value. Mandatory. Year when measurement was taken
2 | Numeric value. Mandatory. Month when measurement was taken
3 | Numeric value. Mandatory. Day when measurement was taken
4 | Numeric value. Mandatory. Measured value. This value is interpreted either as depth or as absolute elevation. Depending on the import format settings. Use -999 to express null.
5 | Alphanumeric value. Mandatory. Correctness of measurement. J is interpreted as correct all other values are interpreted as incorrect. In Redbex an incorrect measurement is stored as erroneous observation.

Table 3: Description of the first 5 cells cells in a data GVR line

If the header of the GVR file specifies that the file contains time the last 8 characters of the line are interpreted as time (format hh:mm:ss).

The data between the 5th cell and the time (or the end of line if no time is given) is interpreted as standard command and free comment. The standard comment is a comment that is interpreted by Redbex by matching that string against the Standard Comment Classification. If a (non-empty) free comment is found that comment will be added as observation comment in the observation's associated data. The standard comment is separated from the free comment by a single space. Maximum length of the standard comment is 25 characters.


Inclinometer

Last edited: 11/8/2017 10:15:02 AM

The inclinometer import type can be used to import data for the feature type Inclinometer.

Data | Notes
Feature Name | New features can be created automatically, observations for already existing features will be appended to that feature.
Type specific observation data | Depth, deviation in A, deviation in B, Zero-reading and Erroneous flag

Table 1: Data that can be imported by this import type

The file format expected by this import type is a text file structured in lines and columns. The text file can include Unicode characters encoded as UTF-8 (which is backward compatible to ANSI with codepage 65001). The file may use a BOM (Unicode byte order mark) to specify the byte order of the character encoding.

A line in the source file must be terminated by line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Leading and trailing white space characters (see table 2) will be automatically trimmed from each line. If the column separator is set to tab (U+0009) tabs will not be trimmed. The first character of a line is defined as the first non-white space character, the last character as the last not white space character.

Lines where the first character is a # (U+0023, UTF-8: 0x23) are treated as comment lines and will be ignored. If the # is contained in a line but not the first character in the line it will be treated as data. Empty lines (after trimming) except the first non-comment line after the first header line are ignored.

Each non-comment and non-empty line is separated into cells by the column delimiter character. The column delimiter character can be set in the import type's settings. Only one column delimiter character is allowed between two columns, i.e. for n columns you need exactly n-1 column delimiters, and column n is the column after the n-1th column delimiter.

The first two non-comment and non-empty lines are treated as header lines. Header lines contain processing information for the import. The first header line is used to define the contents of each column by specifying a column content identifier in each cell. This column content identifier is used by the Application Server to match the data in that column to some characteristic of the inclinometer feature or observation. Columns with a column content identifier that is not recognized by the Application Server are ignored. The second header line is used to define the unit for numeric values if these numeric values are matched against a quantity property in the observation's type specific data property structure.

Table 2 shows the column content identifiers that must be present for this import type. Since the column headers in header line 1 define the contents of each column, the sequence of columns is not important

Column content identifier | Description
FEATURE | Identifying name of the inclinometer feature
OBSERVATION_SAMPLINGTIMESTAMP | Sampling timestamp of the observation
DEPTH | Depth of the observed value
A | Deviation in A
B | Deviation in B
ZEROREADING | Zero reading flag
ERRONEOUS | Erroneous flag

Table 2 column content identifiers that must be present for this import type

Figure 1: Example for an import source file used to import inclinometer data. Note the orange arrows show tabs.


%Text%

Navigation: »No topics above this level«

Interlab (Version 4)

Last edited: 11/8/2017 10:15:02 AM

Interlab is a file format for the transfer of analytical data between database systems, e.g. from water and food laboratories to other database systems. The initiative for the creation of file format was taken by the then Swedish Water and Waste Water Association, VAV (now Swedish Water) in the early 1990s. The first version was published in 1995. Redbex Supports Interlab version 4.0.

For a full documentation of the Interlab standard please refer to the original Interlab specification. This chapter discusses aspects of the Interlab that are relevant for understanding how Redbex will import data from Interlab files.

Syntactical aspects

File name

The Interlab Standard specifies that .lab is the only valid extension for Interlab files. Redbex however does not check the extension for Interlab files but inspects the file contents to check if the file is an Interlab file.

Text encoding

According to the Interlab standard Interlab files can be encoded using UTF-8, UTF-16 or UTF-32. The actual encoding used may optionally be specified in the header of Interlab files using the #Tecken control sequence. Redbex will not use this information in from the header of the Interlab files but will detect the actually used encoding by inspecting Interlab files on a byte level. This approach is more reliable since the actual encoding of a file might easily change while the header of the Interlab file is probably not changed accordingly.

Redbex supports Interlab files in UTF-8 (with or without BOM), UTF-16 or UTF-32 encoding (both little-endian and big-endian).

Line

While not specified in the Interlab standard Redbex defines a line in an Interlab file as a sequence of characters followed by a line feed character (U+000A, UTF-8: 0x0A, typical for Unix, Linux, Android, Mac OS X, BSD, and other operating systems), a carriage return (U+000D, UTF-8: 0x0D typical for Mac OS till Version 9 and other operating systems), or a carriage return immediately followed by a line feed (typical for Windows operating systems).

Trimming lines

When reading Interlab files Redbex will ignore leading and trailing white space characters of each line in the file. White space characters are defined as shown in table 1.

Empty lines

When reading Interlab files Redbex will always skip any empty lines or lines that contain only white space characters (see table 1).

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).

Table 1: White space characters

Comment lines

The Interlab standard does not specify a possibility to add comments to an Interlab file. Deviating from the standard Redbex will interpret every line starting with a $ character as a comment line, and will therefore not parse this line.

Control sequences

Interlab files contain control sequences that advice the reading software product on how to read and interpret the data in the Interlab file. Control sequences always start with a # character followed by a sequence of characters. Control sequences are case insensitive.

Header

An Interlab file always contains a header. The header is a series of control sequences starting with the #interlab control sequence and ending at the first #provadm control sequence.

Data section

A data section consists of a provadm section and a provdat section. A valid data section must always have a provadm and a provdat section, one Interlab file may have multiple data sections. each provadm and provdat section contains one header line, and one or more data lines.

Each line is a sequence of semicolon separated cells of data. According to the Interlab standard the last data cell must also be terminated by a semicolon. Redbex will determine if the last cell is terminated by a semicolon by inspecting the first data line in the first provadm section of the file.

The first line in a provdat or provadm section is the header line, all following lines are data lines. The header line specifies which kind of data is to be found in the cells of the following lines. The type of data is specified in header lines by using strings that are defined in the Interlab standard. Redbex compares these strings case insensitive.

The number of data cells in the header line must match the number of data cells in each data line.

A provadm section starts with the #provadm control sequence a provdat section starts with the #provdat control sequence. The provadm section ends with the #provdat control sequence. The provdat section ends with the #provadm section of the next data section or with the #slut control sequence.

Semantic aspects

Feature name

Interlab uses the Lablittera cell to give each sample a unique id, however multiple samples may belong to the same Redbex feature, this association of sample IDs to features is not defined in the Interlab format. To still be able to import data from Interlab to Redbex, Redbex therefore uses the Specific provplats cell. This cell is optional according to the Interlab standard but Redbex defines it a mandatory and each line in provadm sections must have a non empty Specific provplats cell.

Null

Empty cells are considered as null. Cells containing only a single dash - are also considered as null cells.

Mapping of sample types to feature types

The data in Interlab formats is imported into features of different types according to the value of the provtyp cell in the provadm section setting. Table 1 shows the mapping of provtyp to feature types that is used by the import. The import settings allow you to add additional provtyp identifiers for each supported feature type.

Provtyp | Feature type
Avloppsvatten Dricksvatten Grundvatten Ytvatten Dagvatten/dräneringsvatten Lakvatten Länshållningsvatten Processvatten Spolvatten Släckvatten Tunnelavloppsvatten | Water analysis
Sediment Slam Jord Bergkross Asfalt Betong Sulfidjord Industri och gruvslagg | Soil analysis
Porgas Övrig luft | Air Analysis

Table 2: Mapping of provtypes to feature types

Import settings

Setting | Description
Coordinate system | Interlab files do not contain spatial information, however this setting can be used to create new features with the right spatial reference system
Create classification elements | If set the import will try to create missing classification elements. Note that this is only possible if the user executing the import has appropriate permissions and if a classification is set as

Table 3: Settings of the import type Interlab


Import types

Last edited: 10/25/2017 6:37:06 AM

The Application Server provides multiple import types. An import type encapsulates the logic how to read and process a source file of a specific format.


In situ water characteristics

Last edited: 10/5/2017 11:51:24 AM

Represents characteristics of water that can usually be observed in situ.

Characteristic | Note
Name | In situ water characteristic
Path | \Hydrology
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection | Description
FEATURESTATUS Status Status | Status of the ground water level. Property type: Classification of type Ground water level status
InformationSource Information source Informationskällor | Describes the source of the information recorded for this ground water level. Property Type: Text Default Value: none Display Options: single-line
NOTES Notes Anmärkning | General notes Property Type: Text Default Value: none Display Options: Multi-line
Locationdescription Location description Lägesbeskrivning | Description of the location of the drill hole Property Type: Text Default Value: none Display Options: Multi-line
PositioningType Positioning type Koordinatkvalitet | Property type: Classification of type Positioning type.
PositioningAccuracyHorizontal Positioning accuracy horiz. Kvalitetsangivelse (plan) | Property type: Classification of type Positioning accuracy
PositioningAccuracyHeight Positioning accuracy height. Kvalitetsangivelse höjd | Property type: Classification of type Positioning accuracy

Table 2: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Air temperature AIR_TEMPERATURE | Thermodynamic temperature of water Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -91.5 and Value ≤ 70.7 Display Options: Decimals: 2
Water temperature WATER_TEMPERATURE | Property Type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -50 and Value ≤ 200 Display Options: Decimals: 2
PH Value PH | Property type: Numeric Default Value: null Validation rule: Value ≥ 0 Value ≤ 14 Display Options: Decimals: 2
Redox REDOX | Property Type: Quantity of type Electrical potential difference Default Value: null Default Unit: mV Validation rule: Value ≥ -2000 and Value ≤ 2000 Display Options: Decimals: 2
O2 O2 | Property Type: Quantity of type Mass / Volume Default Value: null Default Unit: mg / l Validation rule: none Display Options: Decimals: 2
Conductivity CONDUCTIVITY | Property Type: Quantity of type electrical conductivity Default Value: null Default Unit: µS/m Validation rule: none Display Options: Decimals: 2
TDS TDS | Total dissolved solids Property Type: Quantity of type Mass / Volume Default Value: null Default Unit: mg / l Validation rule: none Display Options: Decimals: 2
Remarks REMARKS | General remarks Property Type: Text Default Value: none Display Options: Multi line

Table 3: Properties and collections of the type specific observation data property structure


Starting

Last edited: 10/25/2017 6:37:06 AM

The Setup Program will create a Windows Service for the Application Server and will set its startup mode to Automatic. i.e. the Service will start whenever the operating system is started.

If advised in Step 4: Windows Service configuration the Application Server Service will automatically be started after the Installation is finished. If not you will have to start the service manually or reboot the system.


Smart Client

Last edited: 10/25/2017 6:37:06 AM

This section describes the process of installing the Redbex Smart Client on a computer system. Installation is usually straight forward still we recommend to follow all steps as described in this section,

Note that membership in the local Windows Administrators group, or equivalent, is the minimum required to complete the Application Server installation.

The setup installation process consists of some pre-installation tasks and the execution of the Setup Program.


Installation scenarios

Last edited: 10/25/2017 6:37:06 AM

Being an n-tier system and being built to scale easily from smallest projects to the biggest projects Redbex supports a wide range of different installation scenarios. Installation scenarios define where the tiers of Redbex are physically installed. There are numerous considerations that should be taken into account when deciding for a specific installation scenario; among them performance, security and compliance with the structure of your existing IT environment.

For installing the three mandatory components, the Application Server, the Application Server database and the Smart Client there are three common installation scenarios which are described in the following chapters.


Scenario 3: Fully distributed

Last edited: 10/25/2017 6:37:06 AM

If you decide to use this scenario you will install the Application Server Database and the Application Server on separate machines. The Smart Client is installed on all client Computers from where you want to access the Application Server. For the communication protocol between Smart Client and Application Server you can choose TCP if you are on a local area network else use HTTP or HTTPS.

When to use this scenario

·More than one person want to access the Application Server from different locations

·You have an existing Database Server

·You plan do a lot of processing

·You have higher requirements on information security

Pro

·Backup can be handled by a central server

·Load distributed between Database Server and Application Server

·Can be used to access data via Internet

Con

·Database Server and Application Server communicate over possibly slower network connection.

Figure 1: Example of a fully distributed installation scenario


Import types

Last edited: 12/11/2017 11:35:16 AM

The Application Server provides multiple import types. An import type encapsulates the logic how to read and process a source file of a specific format.


%Text%

Navigation: »No topics above this level«

Laboratory analysis

Last edited: 10/30/2017 2:38:52 PM


Manager user

Last edited: 11/8/2017 10:15:02 AM

In Redbex there is no special almighty administrator user nor is there an administrator permission that could be assigned to users. If you want an almighty user i.e. someone who is allowed to access every resource in the system you have to define a user with the appropriate privileges yourself. While this concept sometimes results a little bit more work when configuring privileges it gives you much more control on who can access what in the system. For example it is possible to define privileges in a way that a specific user has all the permission to configure the system, but still has no access on the content itself.

During Installation of the Application Server Database the Setup Program will create a manager user (with a user name and password you choose) that will be granted all necessary permissions to configure the system, these are:

·All System permissions

·All Domain permissions on the root domain.

If in later versions of the Application Server new permissions are added this user will also automatically get these new permissions.

The manager user created by the installer cannot be deleted and cannot be deactivated.

We recommend to use the manager user only for administrative purposes.


Introduction

Last edited: 3/8/2018 7:30:14 AM

MappRover is an iOS based client to the Redbex Application Server that allows a fully digital mapping and documentation process of geo-located characteristics in well defined areas along an axis. It was mainly designed for mapping and documenting geological and geotechnical characteristics during the construction of a tunnel but can also be used for mapping of any kind of geo-located characteristics along an axis.

Redbex MappRoveris designed to be used on tablet devices with pen-support and mimics the traditional way of pen and paper documentation.

The name MappRover is a portmanteau word formed from Mapping, Application or App and Rover and therefore expresses some of the fundamental characteristics of the app.

How MappRover relates to the Redbex Software System

Redbex MappRover is part of the Redbex Software System, i.e. MappRover cannot work without access to a Redbex Application Server and also relies on the Redbex Smart Client as user interface for configuring the whole system and for data evaluation.

While access to the Redbex Application Server is mandatory MappRover can operate without a continuous network connection to that server so that it is fully operable in places where no network connection is available. This of course implies that Redbex MappRover implements a data synchronization procedure that is used to synchronize data that was modified offline with the data on the Application Server.

For most tasks that users can perform with MappRover they do not need any specific knowledge of the Redbex Software System, however an understanding of some basic concepts can be useful.

Redbex is a very generic software product that can be used for many different expert areas, Redbex therefore uses a very generic terminology for data structures and functions. MappRover on the other hand focuses on a very specific task and therefore also uses a very specific terminology, i.e. the same things may be named differently in both systems.

Changed approach

While MappRover was designed around the traditional process of mapping geological characteristics within a tunnel it is not intended to copy this process in every detail. The additional possibilities but also limitations of the hardware and software environment in which the app runs dictates a slightly changed approach.

Not everything that is possible in the pen and paper approach will be possible in MappRover, but on the other hand MappRover provides features that were not possible with the traditional pen-and-paper approach.


Relating buildings and lots

Last edited: 11/8/2017 10:15:02 AM

The Lantmäteriet GSD-Property Map database does not have mapping of properties to buildings. If a building belongs to a property is therefore determined ruing the import by following algorithm:

Algorithm

First we select all lots with Detaljtyp FASTIGHET that intersect the building's geometry and the IntersectionGeometry.Area > 0.5 * BuildingGeometry.Area. I.e. we match buildings to that lot of detailjtyp FASTIGHET on which the building has more thatn 50% of its base area.

Redbex assumes that this matchincan only result in 0 or 1 match.

All the buildings that could not be matched to a lot in the previous step will now be checked if they belong to any lot of other detaljtyp. We check detaljtyps in following order: 3DFASTIGH , SAMF, SAMFO, FASTO. The first match will be used. The condition for a match is different for these detaljtyps. We select all lots with the matching detaljtype where the builind intersects and the building's area is more than 50% on that lot. We then take the lot where the intersection area is gretest.


Midpoint calculation

Last edited: 10/23/2017 10:16:06 AM

When the Map view shows the location of an element as Midpoint that midpoint is calculated differently for different types of geometries and differently for projected and geographic coordinate systems, see tables 1 and 2 for detail.

Geometry | Midpoint calculation
Point | Midpoint is same as point
Multi point | Midpoint is Centroid of the Convex hull if the convex hull is a polygon. Midpoint is Centroid of envelope if convex hull is a line.
Line | Midpoint is Centroid of the Convex hull if the convex hull is a polygon. Midpoint is Centroid of envelope if convex hull is a line.
Multi-line | Midpoint is Centroid of the Convex hull if the convex hull is a polygon. Midpoint is Centroid of envelope if convex hull is a line.
Polygon | Midpoint is Centroid of Polygon
Multi-Polygon | Midpoint is Centroid of Convex hull of Multi Polygon

Table 1: Definition of Midpoint for different types of geometries on a projected coordinate system

The convex hull of a geometry defined on a projected coordinate system is the smallest convex geometry that completely encompasses all the points in a given instance. A convex geometry is one in which no interior angle is greater than 180 degrees, so that the sides do not ever bend inwards or contain indentations.

The envelope of a geometry represents the smallest axis-aligned rectangle that completely encompasses every part of the geometry.

Geometry | Midpoint calculation
Point | Midpoint is same as point
Multi point | Envelope center
Line | Envelope center
Multi-line | Envelope center
Polygon | Envelope center
Multi-Polygon | Envelope center

Table 2: Definition of Midpoint for different types of geometries on a geographic coordinate system

The Envelope center is the average position of all vectors that describe the location of each point in the geometry from the center of the earth. This is a very simple approximation of the center point of any type of geometry based on a geographic coordinate system.


Modular updates

Last edited: 11/8/2017 10:15:02 AM

Some parts of the Redbex Application Server can be updated without actually installing a new version of the Redbex Application Server. The Application Server loads these so called modular updates from the Redbex Distribution Server.

On the first start up of the Application Server (after installing the software) the Application Server will automatically try to perform a modular update, future updates are then manually initiated by the user. Modular updates are loaded from the Distribution Server - it is therefore mandatory that a connection to the Distribution Server can be initiated.

Note: Running the modular updates will automatically log out users from the Application Server who do not have the Create user session when server is closed (13) permission. Additionally the server will be temporarily locked, so that no other user can login.

Note: Depending on the contents in your database a modular update might take from several minutes up to several hours, during a modular update users won't be able to access the Application Server!

Table 1 lists the parts of the Application Server that are installed/updated by the modular update.

Data | Description
Feature types | Will update the list of available feature types. Note that even thought the online update installs feature types it is defined by your license if you can use feature types.
Sensor types | Will update the list of sensor types available for the installed feature types.
Classification types | Will update the classification types used in property structure.
Quantities & Units | Will update the units and quantities available to be used in property structures.
Multi-language texts | Will update texts published by the Application Server in multiple languages.
Allowed feature container relations | Updates the rules that define the feature types that can be member of a specific container feature type.
Report types | Report types for the reporting engine.

Table 1: Parts of the Redbex Application Server that are installed/updated with modular updates

You can initiate a modular data update at any time manually via the Redbex Smart Client. The modular data update will then run in the background as a job. To verify the success of the data please refer to the job success status and the job log.

The user who is running the modular data update must have the system permission Perform Distribution Server update (8)


Hardware requirements

Last edited: 1/22/2018 9:18:50 AM

Redbex MappRover is designed to be used on tablet devices with pen-support and mimics the traditional way of pen and paper documentation. MappRover is currently supports on iPad Pro 12.9" devices only.


Logging

Last edited: 1/29/2018 10:31:54 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Versioning

Last edited: 11/8/2017 10:15:02 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Not_Used_Topics

Last edited: 10/5/2017 11:51:30 AM

Geben Sie hier den Text ein.


%Text%

Navigation: »No topics above this level«

Privilege object types & Permissions

Last edited: 11/8/2017 10:15:02 AM

Each privilege object type has its own set of permissions that can be granted to a privilege subject. following chapters list and explain the available permissions.


PrepareDatabase

Last edited: 11/8/2017 10:15:02 AM

This import type uses a MS SQL Server database as its data source and utilizes the power of the database engine to speed up the data preparation. Therefore Before this import type can be used some preparation of the source database is needed.

The database that the import connects to must contain the source data, and the user connecting to that database must have the appropriate permissions to create and delete tables in that database as well as to read and modify all data.

Since it is usually not wanted that the import process changes the original GSD-Property Map database we recommend that the import connects to a working database which contains views or copies of the data in the original GSD-Property Map database. In the following we discuss different ways how data can be made available.

Making source data available via Linked Server and views

If the original GSD-Property Map database is not on the same database server as the database the import connects to you can create views to the FK_AY and FK_BY tables in the original database by first creating a Server Link and then creating the views using the commands shown in listing 1 and listing 2.

CREATE VIEW FK_AY

AS

SELECT *

FROM OPENQUERY(

[<ServerLinkName>],

'SELECT * FROM [<SourceDatabaseName>].[<Scheme>].FK_AY');

Listing 1: Creating the FK_AY view for a remote database

CREATE VIEW FK_BY

AS

SELECT *

FROM OPENQUERY(

[<ServerLinkName>],

'SELECT * FROM [<SourceDatabaseName>].[<Scheme>].FK_BY');

Listing 2: Creating the FK_BY view for a remote database

Making source data available via views

If the original GSD-Property Map database is on the same database server as the database the import connects to you can create views to the FK_AY and FK_BY tables in the original database using commands shown in listing 3 and listing 4.

CREATE VIEW FK_AY

AS

SELECT * FROM [<OriginalDatabaseName>].[<SchemaName>].FK_AY

Listing 3: Creating the FK_AY view for a local database

CREATE VIEW FK_BY

AS

SELECT * FROM [<OriginalDatabaseName>].[<SchemaName>].FK_BY

Listing 4: Creating the FK_BY view for a local database

Making source data available by copying data

A third way to make the data from the original GSD-Propert Map database is copying the data for the FK_AY and FK_BY tables to the database that the import will connect to. While this approach of course requires you to repeatedly copy the database to get all the latest changes it might speed up the import process (especially when the original GSD database is on a remote server)

Listing 5 shows an example how data can be copied with an SQL script from a Linked Server.

IF (EXISTS(SELECT *

FROM INFORMATION_SCHEMA.TABLES

WHERE TABLE_NAME = 'FK_AY'

AND TABLE_CATALOG = DB_NAME()))

BEGIN

  DROP TABLE FK_AY

END

Select * INTO FK_AY

FROM OPENQUERY(

[<ServerLinkName>],

'SELECT * FROM [<SourceDatabaseName>].[<Scheme>].FK_AY')

Listing 5: Creating the FK_BY view for a local database. Note that this script deletes and already existing table!

Database Permissions

During the preparation of data this import type creates tables in the database it connects to and after import it will delete these tables again. The accessing user therefore needs the appropriate privileges create and delete tables.

Cleaning up the database

After the import the import process will delete tables it created, in terms of an abnormal termination of the import it might however be that these tables are not cleaned up. If this situation happens all tables starting with RbTemp can be manually deleted.


PrintManual_Back

Last edited: 10/23/2017 7:30:20 AM

This Reference Manual is a detailed reference for Redbex. It provides insight on how the Redbex works and what functionality it provides to the user. This manual will give you the basic information to unleash the full power of Redbex and use it in an effective and creative way.

The price of the generic approach and the flexibility of Redbex is, that to use the product to its full potential, you should have at least basic knowledge of the concepts behind. Therefore this manual provides deep insights and contains information for first time users as well as power users and system administrators.


PrintManual_EndNotes

Last edited: 10/23/2017 7:30:16 AM


PrintManual_Foreword

Last edited: 10/5/2017 11:51:48 AM

Something to say


PrintManual_Title2

Last edited: 10/23/2017 7:33:44 AM

Redbex Reference Manual

Published by Pöyry Infra GmbH, Rainerstr. 29, 5020 Salzburg, Austria

Copyright © 2018 Pöyry Infra GmbH. All rights reserved. No part of the contents of this Reference Manual may be reproduced or transmitted in any form or by any means without the written permission of the publisher.

The Redbex name and the Redbex logo are registred trademarks of Pöyry Infra GmbH, Austria.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this Reference Manual, Pöyry Infra GmbH was aware of a trademark claim, the designations have been printed in caps or initial caps.

While every precaution has been taken in the preparation of this Reference Manual, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.


PrintManual_WiseWords

Last edited: 10/5/2017 11:51:48 AM


Real estate

Last edited: 10/25/2017 6:37:06 AM

Represents a property defined as a geographical area

Characteristic | Note
Name | Property
Path | \Land register
Feature type icon |
Feature type class | Group
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | Projected coordinate system
Allowed geometries | Polygon, Multi-Polygon
Allowed contained feature types | Surface object TMO building

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection Identifier | Description
OBJECTID | Internal Universally unique identity (UUID) for the real property.
FNR_FDS | Official Property number, this is not unique! Estate can be devided into more than one area in this case the FNR_FDS is duplicated In that case OMRNR will be set. Real property key in the Real Property Register (210002312)
OMRNR | Is 0 = null? Area number (3). 0 is treated as an empty value Needed in Redbex?
EXTERNID | Do we need this in Redbex Does the content have any specific format? Split? External ID from Lantmäteriets basic data. Taken from the AI layer. For share in an unregistered joint property unit EXTERNID=ANDELSFASTIGHET.
DETALJTYP | Real names for this? Is this a fixed classification? Detail type code (FASTIGHET, SAMF, FASTO, SAMFO)
KOMMUNKOD | County and municipality code (2180)
KOMMUNNAMN | Municipality name (GÄVLE)
TRAKT | District name (BY)
BLOCKENHET | Split? Block and unit (1:3)
FASTIGHET | Split? Real property area: District_block:unit_area number (BY 1:3>3)
YTKVAL | Geometric quality of polygons. Values: 1,2,6. 0 is treated as an empty value. See detailed description below. Classification!
ADAT | Date/time of most recent change. Note, does not need to be latest revision. Format: 2005-10-18 12:04
FASTIGHETBV | Split? Values: Oregistrerad samfällighet or empty value
LAN_KOD | No documentation found
IMPORTDATUM | Needed?
Shape |

Property structure for type specific observation data

This feature type defines not property structure for type specific observation data.


Property_Temperature

Last edited: 10/23/2017 7:33:44 AM

Represents the thermodynamic temperature

Property type: Quantity of type Thermodynamic temperature

Default Value: null

Default Unit: °C

Validation rule: Value ≥ -273.15

Display Options: Decimals: 5


Property_ZeroReading

Navigation: »No topics above this level«

Zero reading property

Last edited: 10/23/2017 7:33:44 AM

Used for marking the observation as zero reading observation

Property type: Boolean

Default Value: false

Validation rule: none

Display Options: none


Property structures

Last edited: 11/8/2017 10:15:02 AM

Property structures (PS) are templates for data structures that are used to store data for features and sensors that is specific to the feature type or senor type. Table 1 lists the places where property structures are used.

When a PS is used to store data for a specific object, the Application Server creates a property structure instance (PSI) and fills that instance with data.

Property structure usage | Description
Feature types, type specific feature data | Defines the type specific data that can be stored along with each feature of a specific feature type. This property structure is called the Feature PS.
Feature types, Type specific observation data | Defines the type specific data that can be stored along with each observation in a feature of a specific feature type. This property structure is called the Observation PS.
Sensor types, type specific sensor data | Defines the type specific data that can be stored along with each sensor of a specific type. This property structure is called the Sensor PS
Sensor types, extended chronological | Defines the type specific data that can be stored along with each chronological sensor configuration of a sensor of a specific type. This property structure is called the Chronological sensor PS.
Sensor types, extended observation configuration | Defines the type specific data that can be stored along with each observation that uses a sensor of that specific type. This property structure is called the Sensor observation PS.

Table 1: Areas where property structures are used

While there is some data that is common to all features, sensors, observations etc., property structures are used to store the data that is specific to a specific feature type, sensor type etc.

Property structures cannot be defined or changed by the user but are distributed as part of feature types, sensor types etc, however there are numerous possibilities to configure property structures.

For the technically inclined: a property structure is a dynamic data structure used to store data efficiently without changing the underlying database structures. This allows for distribution of new feature types or sensor types without having to update the database or the Application Server.


Configuration context

Last edited: 11/28/2017 11:08:28 AM

Each property structure configuration is defined for a feature context, i.e. is applicable only in a specific environment. The context defines under which circumstances the configuration is applicable. This allows you to define different property configurations for the same property structure.

While for a given property structure you can only define one property structure configuration for a specific context, there might be more than one property structure applicable to a specific property structure instance due to inheritance.

E.g. if you define a property structure configuration for the type specific feature data of a specific feature type in a domain, a feature in a sub-domain will inherit that configuration even though a separate property structure configuration might have been defined for the sub- domain.

Table 1 shows the contexts that are used for different property structures

Configurations for | Definition context
type specific feature data, type specific observation data | Feature context
Sensor type specific data, chronological sensor configuration type specific data, sensor observation data | Sensor context

Table 1: Contexts that are used to define the applicability of property structure configurations

When the system searches for property structure configurations for a property structure instance that is used in a specific context it will search for all property structure configurations that are defined in exactly that context or in a context that is superior. For a specific property or collection within the property structure instance the actually used configuration is determined either by unifying all configurations for that property structure or by taking the first matching configuration. Table 2 shows the determination strategy for different setting types.

Setting type | Determination strategy
Validation rules | Unify, All validation rules are verified
Display settings | First match
Alarm conditions | Unify
Default values | First match
Mandatory setting | First match

Table 2: Determination strategies for different setting types


Mandatory setting

Last edited: 11/28/2017 11:08:26 AM

Mandatory settings define if a specific properties value must be given before it is stored. The mandatory setting can be defined for each property in a property setting context

For some properties system predefined value for mandatory may be available. This value is not modifiable by the user. If system setting is TRUE, property is mandatory, disregarding any user settings. If system setting is FALSE, user setting in current context is used.


Property collections settings

Last edited: 11/28/2017 11:08:26 AM

The system allows to limit the number of elements within property collections by defining validation rules for the minimum and maximum allowed elements in the collection. Note that as all other validation rules they do not prevent you from storing invalid data, but can be evaluated to detect invalid data.


Default values

Last edited: 11/28/2017 11:08:26 AM

For properties of most property types you can define default values. Whenever a new instance of a property structure is instantiated the properties that have default values defined in the current property setting context are set to that value. Additionally the user can reset a properties value to it's default value. Besides the user defined default values the property structure itself might define system default value that is not modifiable by the user. If a user defined default value and a system value are given the user defined default value overrides the system default value. When a property default value is defined it is not checked against the validation rules of the property.

The effective default value used is determined by a first match approach.

Note: the default value is copied to the property data and not linked, therefore if you change the default value later on it will not change any property values.


Display settings

Last edited: 11/28/2017 11:08:26 AM

All property types have configuration options that define how the property and its value is displayed (in user interfaces, reports etc.). Besides user defined display configuration the property structure might define default display settings. The effective display settings used are determined by a first match approach.

Note: Display settings are defined for a property but need to be implemented by the client that displays data.


Validation rules

Last edited: 11/28/2017 11:08:26 AM

Validation rules can be used to validate data for properties before they are stored. There may be predefined system validation rules and user defined validation rules for each property.

All validation rules for the property that are defined (both system and context specific) are checked when value is modified. If one of the validation rules fail the property value does not validate.

Note: Validation rules are checked only when data is stored. Changing existing validation rules or creating new validation rules does not re-check already stored data. Therefore you might have data in your system that is not valid according to the current validation rules.

Validation rules are mainly intended to help the user when data is entered manually, usually data is imported from other systems (via files or online connection) validation rules do not make sense since you usually want the original data in your system. Additionally, checking validation rules takes time to process - so when huge amounts of data are stored it is wise not to have validation rules in the property setting context of the feature that stores this data.

All validation rules for feature data or observation data can be enabled or disabled together for a feature.


Relating properties and blocks

Last edited: 10/25/2017 6:37:06 AM

This relation is kind of hard coded


Reporting

Last edited: 10/5/2017 11:51:34 AM

This topic is not yet finished in this version of the Reference Manual. Please contact support if you need more information regarding this topic.


Deleting linked features and observations

Last edited: 12/14/2017 6:43:50 AM

The Application Server provides the possibility to delete features and observations linked to an import session. When deleting the features and observations for an import session following content will be deleted:

·all features created the import session

·all observations created or altered by that import session, even if these observations have been modified after the import. Will also delete any associated data for these observations

For more information on what data is destroyed when deleting a feature or observation please see chapter Deleting features and observations.

Note that the deleting of linked features and observations this is therefore not a full featured undo of an import session and shall therefore be used with caution. Anyhow it can be a useful functionality in cases when you encounter wrongly imported data.

Deleting of linked features and observations will of course respect the current permissions the user has on features and observations, therefore it is be possible that a user cannot delete features and observations created by an import session that this user ran. In that case the Application Server will revert all changes where permissions are granted all other changes will remain untouched.


Row settings

Last edited: 10/25/2017 6:37:06 AM

Each row in an axis section drawing is of a specific row type. Redbex pre-defines the available row-types. Each row type has its own UConfiguration that allows the user to specify settings that influence how a specific instance of that row type will be rendered.

Table 1 describes the UConfiguration settings common to all row types.

Setting | Description
Hidden | If set this row will not be rendered. This setting might be useful while designing your axis section drawing definition to temporarily disable rendering of specific rows.
Height | Height of the row given in mm. Default: 20mm Validation > 0.1
Header | The title of the row shown in the row header
Sub-header | Subtitle of the row shown in the row header
Row Header drawing | A raster image that will be shown in beneath the reader and sub-header. The raster file will be scaled to fit into the area of the header. Note that the size of the raster file must be < 24 KiB
Header font color | Defines the color used for the row header and sub-header. Default: Black
Header font bold | Defines if the row header shall be shown in bold face. Default: false
Background color | Defines the background color for the row. The background color will be used in the row header, row legend and in the row content.
Data font color | Defines the color for text shown in the content area of a row.
Data font size | Size of the font used for texts in the content area of a row. Given in millimeters. Default: 2 Validation: > 0.1 and ≤ 100

Table 1: Common settings for all rows

Each row can define its own vertical grid. If so the definition of the vertical grid will override the global definition of the vertical grid for this row. Table 2 shows the available settings for the vertical grid.

Setting

Description

Show vertical grid

Defines if a vertical grid is displayed for this row.

Default: false

Color

Sets the color of the graphical elements that are used for the vertical grid. If not set (null) the default color of the axis section drawing settings will be used.

Default: null

Major ticks distance

The distance between two consecutive major ticks; given in the linear unit of the used axis reference system. If not set (null) the default color of the axis section drawing settings will be used.

Default: null

Validation: > 0.0

Minor ticks between major ticks

Defines how many minor ticks shall be shown between two major ticks. If not set (null) the default color of the axis section drawing settings will be used.

Default: 9

Validation: ≥ 0.0

Grid style

Defines the style of the grid display. If not set (null) the default color of the axis section drawing settings will be used.

Following options are available

·Style 1: Major ticks are lines from top of row to bottom, minor ticks are short lines starting at the row bottom

·Style 2: Major ticks are lines from top of row to bottom, minor ticks are short lines starting at the row bottom and a mirrored short line starting from the row top

Gird Z-Order

Defines if the Grid (vertical and horizontal) is shown behind or in front of other elements in this row.

Options are

·In Back

·In Front

Default:In Back

Table 2: Axis section drawing settings for the vertical grid


Versioning

Last edited: 11/8/2017 10:15:02 AM

Over time the Smart Client will be deployed in different versions, new features might be added, bugs removed etc. To distinguish between different versions of the Smart Client each version has a unique version number. Version numbers consist of four components: major, minor, build, and revision e.g. 1.38.16312.16318. All components are integers greater than or equal to 0. The format of the version number is as follows:

<major version>.<minor version>.<build number>.<revision>

The components are used by convention as follows:

·Major: A higher major version number indicates a major rewrite of a product or significant new functionality.

·Minor: If the major version number on two Smart Client versions are the same, but the minor version number is different, this indicates functionality enhancements.

·Build: A difference in build number indicates a new version with no significant new features implemented, but small improvements and bug fixes.

·Revision: A difference in revision number indicates a new version with small changes, mostly bug fixes.

Figure 1: The version of the Smart Client is shown on the Smart Client in the Backstage View

Application Server version compatibility

When the Smart Client connects to the Application Server it first gets the Application Server Version and checks if it supports that version. This is done by comparing the major and minor component of the Application Server version number to a compatibility version number that is hard coded within the Smart Client. If the Smart Client does not support that Application Server version you will not be able to connect.

Depending on your configuration (see also Smart Client common settings) of your Smart Client the Smart Client can automatically try do download a new version whenever it detects an incompatibility with the Application settings.

it will not connect but will try to download a version of the Smart Client that is compatible with the Application Server Version.

Example: If the Application Server compatibility number stored within the Smart Client is 2.3 the Smart client can connect to any Application Server whose version number has major component 2 and minor component 3.


Feature Explorer

Last edited: 11/8/2017 10:04:52 AM

The Feature Explorer is a tool window used for listing features, it is the main place from where you can access features (including their observations) and from where you can start a multitude of feature-related actions.

You can open the Feature Explorer from the Content & Structure Ribbon tab. The Feature Explorer will be automatically opened on the first start of the Smart Client. Since the Feature Explorer is the main window from which you can access features (including their observations) and many other feature-related functionality we recommend to leave this window open all the time.

The Feature Explorer has three main Panels: View Members (showing the result of a view execution), Selection (showing the current user's personal selection of features) and Feature Sets (sets of features that defined by the current user).

Using the drop-down list on the bottom of the window (figure 1: 1) you can manually switch between these Panels. The Smart Client will however automatically change to a specific Panel whenever the user performs an action that influences the data shown in that panel.

Figure 1: Switching between different panels of the feature explorer

The window's toolbar will change according to the selected panel, the Refresh button an the Node visibility button are however always shown. (Figure 1:2, 1:3). The information bar below the toolbar displays information about the displayed features, depending on the panel.

Features tree

Each Panel contains a tree view control that shows all features relating to this panel as root nodes. By expanding a root node you can explore the relations of this feature to other features. Which type of relations will be shown depends on the user's definition of node visibility that can be changed by opening the node visibility window from the toolbar (figure 1:3).

The layout of the tree views and the actions you can perform on the features shown there are nearly identical in each Panel.

Each feature displayed in the tree view shows plenty of information that allows you to gather the most important information of the feature quickly. Each feature is shown with the icon of the feature type or the feature subtype. If an icon was defined for that feature's subtype - see figure 1:2. The icon may have an overlay (a small badge added to the icon) so show specific characteristics of the Feature. Table 1 shows the used overlays.

Figure 2: Display of features in the Feature Explorer

Icon | Notes
 | Feature with calculation data source (black ∑ overlay)
 | Feature with connector data source (blue connector overlay)

Table 1: icon overlays used in the Feature Explorer.

Right to the feature type icon the Feature name is shown (figure 2:4). Names of deleted features will be displayed using light gray text. color .

The colored vertical bar left of the feature type icon (figure 2:2) shows the current Approval status of that feature, each approval status corresponds to a color as shown in Table 3.

Color | Description
 | In Progress
 | Ready
 | In Approval
 | Approved
 | Approval denied
 | Approved but erroneous
 | Approval aborted
 | Approval exired

Table 2: Color codes for the approval status of a feature

Right to the feature name (figure 1:5) additional icons are shown for specific features. Table 3 shows the icons that may be shown and their meaning.

Icon | Description
 | Feature is a platform feature
 | Feature is part of a platform feature
 | Observation monitoring is turned off for this feature

Table 3: Additional icons used for describing specific feature characteristics

The tool tip text on each feature (figure 1:6) shows the feature name and other information about the feature.

The tree view allows you to select a single or multiple features, using the context menu you can then perform several actions on the selected features. The context menu will change depending on the selected features. The actions that can be selected from the context menu are nearly identical in each panel of the view browser.

The tree view on each panel can be filtered quickly by using the Filter box.

Opening Features

To open a feature, i.e. to open the Feature Editor window for a the selected feature you can select Open from the context menu of the feature or can just double click the feature in the Feature Explorer. Opening feature from the context menu will only be available if for up to 10 selected features, i.e. you can open 10 features in 10 instances of the Feature Editor at once.

If there is a specialized Feature Editor Window for the feature type of the selected features (e.g. for the document folder feature type) the context menu will include entries to open the feature with those specific windows or with the Feature editor.

When selecting Open from the context menu or when opening the Feature Editor by double clicking a feature the Smart Client will check if a Feature Editor for that specific feature was already opened, and if yes will show that instance of the Feature Editor. However if you intentionally want to open the same feature two times (e.g. for comparing data etc) you can select Open in new instance from the context menu (in this case please also remember that you are working with disconnected data7 ).


Coordinate System

Last edited: 3/8/2018 7:30:14 AM

This document window is used to display and modify a coordinate system. You can open the window from the Coordinate Systems window.

The Protected coordinate system checkbox is read-only; If selected the currently opened coordinate system is one of the coordinate systems that were predefined by Pöyry Infra GmbH and cannot be modified or deleted.

The Name box is a mandatory, i.e. you cannot save coordinate systems with an empty name.

In the Unit box you can describe the used measurement unit. This value is descriptive only. The unit used for converting data between different vertical coordinate systems is encoded in the WKT box.

The WKT (Well Known Text) box is used to specify the properties of the coordinate system in WKT format. On saving the WKT will be validated, you can only save if the WKT is valid.

Figure 1: The Coordinate System window.


Observations tab

Last edited: 10/5/2017 11:51:38 AM

The Observations tab of the Feature Editor window provides access to the observations of a feature.

The Observations tab can present observations of a feature in two different modes: Single view or tabular view mode. In Single view you will see one observation at a time

in tabular view you will see all observations in a table however this view cannot display hierarchical property structures and does also not support all property types. You can switch between these view modes using the Single View and Tabular View toolbar buttons.

The Single View supports supports hierarchical property structures and also supports all property types. The properties of a single observation can be alternatively displayed using the Hierarchical list, hierarchical form or a custom presentation.

The tabular view does not support hierarchical property structures i.e. it will only display properties on the first level of any property structures. The tabular view also has limited support for property types. e.g. a property of type multi-select classification will not be shown in the tabular view.


Relations tab

Last edited: 10/5/2017 11:51:38 AM

This topic is not yet complete. A later version of this topic might be available, please visit the online documentation at doc.redbex.com or download a later documentation version from http://download.redbex.com. Please contact technical support if you need more information on this topic.


Text Viewer

Last edited: 11/8/2017 10:15:02 AM

The Text Viewer window is a document window that can display any textual information. The Smart Client uses the Text Viewer in may cases to display textual information from different sources.

The text window cannot be opened from the Ribbon since it always displays information that is available in a specific context. The displayed text in the text window cannot be modified.

Figure 1: The text window displaying an action log.

To save the displayed text to a file select the Save text to file button (figure 1:1) and specify the location and name of the file in the appearing save dialog. This will save the all of the displayed text as a UTF-8 encoded text file..

To copy the whole displayed text to the clipboard select Copy text to clipboard (figure 1:2), alternatively you can just select a part of the text and user Ctrl+C to copy it to the clipboard.


View

Last edited: 11/8/2017 10:15:02 AM

The View window is a document window used to create and modify views. The window can be opened from the context menu of a view in the View Explorer window.

On the General tab the Name box shows the name of the view. Each view must have a (non empty) name, maximum length for a view name is 200 characters. The system does not check a view name for uniqueness, but we suggest you choose unique names at least within one hierarchy level.

The description box can be used to describe the view. This description is also shown as tool tip on the view in the View Explorer window.

The Sequence number can be used to define the order in which views will be displayed in the View Explorer window. New views will by default have a sequence number of zero. You can use any integer (negative or positive). In one hierarchy level views with lower sequence number will be displayed before views with a higher sequence number. In the View Explorer window views of one hierarchy level will be sorted first by sequence number and then by name.

The Personal view switch is enabled only on creation of a new view. If you modify an already existing view this check box will be read only. If selected, the view is a personal view and therefore only visible to the current user. Root views cannot be marked as personal views.

The Non-listing view check box defines if the view or not see chapter Non listing views for more details.

You can assign a color to a view, this color is used by the Smart Client (and probably other clients) to display the view.

On the View Filter tab you define the actual filter criteria that defines the members of the view. This tab consists of two main areas. The Expression tree area shows the tree-like structure of the view filter expression, the Details area shows details about the combination node or filter term currently selected in the Expression tree.

In the Expression tree combination nodes are shown with a chain link symbol (Figure 1:1) and the logical operator they represent; possible logical operators are: AND, OR, NOT AND, NOT OR . If you select a combination node in the Expression tree you can configure the logical operator in the Details area. The context menu of a combination node allows you to add subordinate combination nodes or filter terms. All combination nodes except the root node can be deleted. Deleting a combination node will also delete all its subordinate combination nodes and filter terms.

Filter terms are shown with a blue ball symbol and a textual representation of the filter term (Figure 1:2). The textual representation does not always describe all settings of the term, it is just a hint to quickly assess the term. If you select a filter term in the Expression tree you can configure the properties of this filter term in the Details area. Every filter node type has it own properties described in chapter View filter terms.

The context menu of a filter term node allows you to delete that filter term node.

The check box left of each term or combination node deactivates the term or combination node. This can be useful when designing your view terms. Note that a view with no term node or with no active term node will always return in an empty view member set.

Note that the Application Server will always check the supplied expression tree on saving. If the expression tree does not actually filter for any data the Application Server will modify the expression tree by adding a Contradiction term (if view is a root view) or a Tautology term (if view is a subordinate view), or by enabling combination nodes.

The Test filter expression button in the toolbar allows you to test the view filter expression. You have to save any changes the view to make this button enabled. Selecting Test will execute the view with the (modified) filter definition and show the results in the Feature Explorer window.

Figure 1: Example of a view filter as displayed in the Expression tree.

On the View Order tab you define how the member features of the view will be ordered when the view gets executed. See chapter View ordering for a description of available view orderings.

The Domains tab allows you to associate a view with one or more domains. To associate the view with all domains use the respective Switch. To associate a view only with specific domains drag those domains to the list of domains. Note that the association is not inherited by subordinate domains. or subordinate views.

The Workspaces tab allows you to expose the current view as one or more workspaces. If this tab is active the toolbar shows the Add new workspace drop-down button. From this drop-down button you can select a workspace type and create a new workspace of that type. To edit an existing workspace select the workspace in the list view and select Edit from the context menu of the list entry or double click a workspace. Creating and modifying a workspace will bring up the Workspace window. To delete a workspace select delete from the context menu of that workspace or press Del.

Figure 2: The View Editor window with the General tab opened

Figure 3: The View Editor window with the Filter tab opened

Figure 4: The View Editor window with the View Order tab opened

Figure 5: The View Editor window with the Domains tab opened

Figure 6: The View Editor window with the Workspaces tab opened


View Explorer

Last edited: 11/8/2017 10:15:02 AM

The View Explorer is a tool window that displays the view structure. The View Explorer can be started from the Common Ribbon tab. The View Explorer will display all views in the view structure for which you have the appropriate permission.

The views displayed in the tree are loaded on demand, i.e. whenever you expand view to see its subordinate views the data will be loaded from the Application Server. Only the root views will be loaded immediately when the window is opened.

The views in the Vie Explorer are sorted by Sequence number and then by view name. The view name is shown in the color defined by the view (default is black).

The icons used in the tree view show specific characteristics of the view, see table 1 for a summary.

Characteristic | Icon | Notes
Public view |  | A yellow folder icon is used for public views
Private view |  | A blue folder icon is used for personal views
Hidden view |  | If a view is hidden for the current user a hidden badge will be overlayed.

Table 1: Characteristics of views expressed as icons

In the View Explorer you can search for views by view name. The search area beneath the window's tool bar (figure 1:1) can be used to quickly search for a view and highlight the found views. In the search area you can enter a the search pattern. If the search pattern includes one or more wildcard characters (see table 1) it will search for all views that match the search pattern. If none of these wildcard characters are present the Application Server will search for all view names starting with the search pattern string.

After changing the search pattern press Enter to search for the first match press Enter repeatedly to search for the next matches.

Wildcard character | Description | Example
% | Any string of zero or more characters. | %Name% matches AB Name as well as AB Name CD as well as Name1 %Name% does not math AB Nam CD %Name does not math Name CD
_ | Any single character. | Feature _ matches Feature 1 as well as feature A
[] | Any single character within the specified range ([a-f]) or set ([abcdef]). | Feature [12345] matches Feature 1, Feature 3 but not Feature 9
[^] | Any single character not within the specified range ([^a-f]) or set ([^abcdef]). | Feature [^A-M] matches Feature M to Feature Z but not Feature A to Feature M

Table 1: Wildcard characters that can be used within the search pattern

Executing a view

To execute a view choose Execute from the view's context menu our double click the view. The filter expression that is associated with the view will then be executed on the Application Server and the resulting features (view members) will be returned. The view members will be displayed in the Feature Explorer window. If the Feature Explorer is not opened at the time the view was executed it will automatically show the resulting features once it is opened. The Execute context menu item is not available if the view is a non listing view.

You can also choose to Execute to selection to execute the view and place the result of the execution in the Feature Selection.

If you are working repeatedly with specific views you can make those views your personal favorites, they will then appear in the favorites window and you can quickly execute this view from there. To make a view a favorite open the context menu for that view and select Add to favorites. Deleting a favorite is done from the Favorites window.

Creating, modifying and deleting views

To edit a specific view select Edit from the view's context menu, this will open up the View window for the selected view.

To create a new root view select the Create root view button from the toolbar, this will open up a View window where you provide the details of the new view. You need the System permission All permissions on root views (1) to create root views

To create a subordinate view of a specific view select Create subordinate view from the context menu of the parent view. This will open up a View window where you provide the details of the new view. You need the view permission Modify view (0) on the parent view to create subordinate views.

You can copy the definition of a specific view by selecting the source view and then selecting Copy from the context menu. Afterward you can create a copy by either pasting the definition as a new subordinate view of a selected view or by pasting the definition as new root view. Of course pasting only works if you have the appropriate permission.

It is not possible to change the parent view of a view. If you want to move a view beneath another parent view you can just copy the view definition. Note that copying a view does not copy the privileges defined for that view.

Deleting a view can also be triggered from the context menu. Note that deleting a view will automatically delete all subordinate views of that view; it will not delete any view members.

Hiding views

To hide or show a view select the Hidden for all users ore Hidden for current user toggle menu entry from the views context menu (figure 2). Hidden views will only be shown in the View explorer if the Show hidden views toggle button (figure 2:1) is selected in the window's toolbar

Domain focus

The view Explorer will by default react to the Data Domain Focus, i.e. the views shown in the View Explorer are filtered according to the current Data Domain Focus. You can disable this filtering by selecting Ignore Data Domain Focus on the toolbar (figure 1:2).

Figure 1: The view explorer

Figure 2: The View Explorer window showing hidden views.


Sensor types

Last edited: 10/5/2017 11:51:40 AM

Sensor types are the basic templates that define which data can be recorded for a sensor of that type and which sensor specific data can be stored for observations done by sensor of that type.

Sensors are always of a specific sensor type. A sensor of a specific type can only observe features of specific feature types. Which sensor type can be used with what feature type is defined by Pöyry Infra GmbH and cannot be changed by the user.

The sensor type defines property structures for type specific sensor data, chronological sensor configuration and observation sensor configuration.

Sensor types are modular. i.e. new sensor types can be installed easily when published by Pöyry Infra GmbH. Sensor types are deployed via the Distribution Server.


Setting a users password

Last edited: 11/8/2017 10:15:02 AM

For a user to be able to connect to the Application Server he needs a user name and a password. The user name is defined when a user is created (and can also be changed afterwards).

For users with Authentication type Local

Users with the system permission Manage users and user groups (0) can advice the Application Server to set or reset the password of a user, if the authentication type for that user is set to local.

The Application Server will then assign a new random password to the specified user that matches the password quality rules defined in the Global Settings. The new password will be sent via email to the email address associated with that user. The Email will contain all information the user needs to logon to the Application Server.

After the Application Server set or reset the password of a user it will force the user to change his password on the next (or first) login.

Note that there is no way for the user who initiates resetting a password to know the new password of the user.


Snipplet_Ja

Last edited: 10/5/2017 11:51:48 AM

Sprick- omvandlingstal Ja | Beskrivning | Φr [°] | Ja
a) Bergkontakt vid skjuvning (inga fyllnadsmineral, endast ytbeläggning).
A | Tät, läkt, hård, ej deformationsmjuknande, impermeabel fyllning, dvs. kvarts eller epidot. | - | 0.75
B | Opåverkade (ej omvandlade) sprickytor, endast missfärgning av sprickytan (beläggning). | 25-35 | 1.0
C | Svagt omvandlade sprickytor. Ej deformationsmjuknande mineralbeläggning, sandiga partiklar, lerfritt krossat berg, etc. | 25-30 | 2.0
D | Siltig eller sandig lerbeläggning, låg lerfraktion (ej deformationsmjuknande). | 20-25 | 3.0
E | Deformationsmjuknande eller lågfriktionsbeläggning av lermineral, dvs. kaolin och glimmer. Även klorit, talk, gips, och grafit, m.m., och små kvantiteter av svällande lera. | 8-16 | 4.0
b) Bergkontakt uppnås före 10 cm skjuvdeformation (tunn mineralfyllning).
F | Sandiga partiklar, lerfritt sönderdelat berg, etc. | 25-30 | 4.0
G | Kraftigt överkonsoliderad, ej deformationsmjuknande lermineralfyllning (kontinuerlig, < 5 mm tjocklek). | 16-24 | 6.0
H | Medel- eller lågt överkonsoliderad, deformationsmjuknande, lermineralfyllning (kontinuerlig, < 5 mm tjocklek). | 12-16 | 8.0
J | Fyllning av svällande lera, dvs. montmorillonit (kontinuerlig, < 5 mm tjocklek). Värdet av Ja beror på andel (%) av svällande lerpartiklar och tillgång till vatten, etc. | 6-12 | 8-12
c) Ingen bergkontakt uppnås vid skjuvning (tjock mineralfyllning).
KLM | Zoner eller band av krossat eller sönderdelat berg och lera (se G, H, J för beskrivning för lerförhållanden). | 6-24 | 6, 8, eller 8-12
N | Zoner eller band av siltig eller sandig lera (ej deformationsmjuknande). | - | 5
OPR | Tjocka, kontinuerliga zoner eller band av lera (se G, H, J för beskrivning för lerförhållanden). | 6-24 | 10, 13 eller 13-20


Snipplet_Jr

Last edited: 10/5/2017 11:51:48 AM

Sprickråhetstal, Jr | Beskrivning | Jr
a) Bergkontakt vid skjuvning, samt b) bergkontakt uppnås före 10 cm skjuvdeformation.
A | Diskontinuerliga sprickor. | 4
B | Råa eller ojämna, vågformiga (böljande) sprickor. | 3
C | Släta, vågformiga (böljande) sprickor. | 2.0
D | Glatta (blankslag), vågformiga (böljande) sprickor. | 1.5
E | Råa eller ojämna, plana sprickor. | 1.5
F | Släta, plana sprickor. | 1.0
G | Glatta (blankslag), plana sprickor. | 0.5
c) Ingen bergkontakt uppnås vid skjuvdeformation.
H | Lermineralhaltiga zoner, med tillräcklig tjocklek för att förhindra bergkontakt. | 1.0
J | Zon med sandigt, grusigt eller krossat bergmaterial med tillräcklig tjocklek för att förhindra bergkontakt. | 1.0

Notera:

i.Beskrivningen syftar på, i följande ordning, småskaliga egenskaper och mellanskaliga egenskaper.

ii.Lägg till 1.0 om medelsprickavståndet av betydande sprickgrupper är större än 3 m.

iii.Jr = 0.5 kan användas för plana, glatta sprickor som har stänglighet, förutsatt att stänglighetens orientering ger minsta möjliga hållfasthet.

iv.Val av värde för Jr och Ja görs för den sprickgrupp eller diskontinuitet som är minst gynnsam för stabiliteten med avseende på både orientering och skjuvmotstånd,τ [där τ ≈ σn tan-1 (Jr/Ja)].


Snipplet_Attribute_Waterflow

Last edited: 11/21/2017 12:45:18 PM

1 dropp = 0,24 ml

Begrepp | Antal droppar/minut | Liter/minut, q
Torr | --- | Inget synligt vatten
Fukt | <1 | Fukt syns längs sprickytor
Mindre dropp | 1-6 | 0.00024-0,00144
Dropp | 6-150 | 0,00144-0,036
Rinnande | >150 | 0,036-0,5 l/min
Kraftig rinnande | --- | >0,5 l/min


EditingStatus_Table

Last edited: 10/5/2017 11:51:48 AM

State name | Description
In process | The object is still in process, and does not yet have reliable data
Ready | The object's data is thought to be complete and accurate.


Snipplet_GS_PasswordQuality

Last edited: 10/5/2017 11:51:48 AM

Setting name | Description
Password quality: Must include digits | If enabled, passwords must contain at least one digit [0-9] Default: false
Password quality: Must include lower and upper-case letters | If enabled passwords must contain at least one letter out of the range [a-z] and one letter out of the range [A-Z] Default: false
Password quality: Must not contain name | If enabled, passwords are not allowed to contain the username. This rule is checked case insensitive. Default: true
Password quality: Must include special character | If enabled passwords must contain at least one the following characters ! @ # $ % ^ & * ? _ ~ - £ ( ) . , = + Default: false
Password quality: Must not contain username | If enabled, passwords are not allowed to contain the user's first, middle or last names. This rule is checked case insensitive. Default: true
Password quality: Minimum length | Defines the minimum length (number of characters) a password must have. Although we do not recommend to allow empty passwords, setting this value to 0 will allow empty passwords. We also do not recommend to use values lower than 8 for this setting. Default: 8


Snipplet_GS_SMTPSettings

Last edited: 10/5/2017 11:51:48 AM

Setting name | Description
SMTP: Server | Server to use for sending out email. This can be the IP-Address or DNS name of the server. E.g. smtp.mycompany.com or smtp.gmail.com
SMTP: Port | Port on which the smtp server listens. Non-SSL Servers often use port 25 SSL servers often 465 Default: 25
SMTP: User name | Defines if communication with the SMTP server should be done over SSL Default: false
Timeout | Timeout when communicating with the SMTP Server, if the SMTP Server does not answer within that time the server is considered as down. Default: 30
SMTP: Sender address | If SMTP: Use sender's email address is not set this email address is used as the From: address in all outgoing emails. If <%GS_SMTPREQUIREAUTHENTICATION%> is set this is used as the login for the SMTP server. Default: <empty>
SMTP: Sender name | If SMTP: Use sender's email address is not set this is used as the sender name in the From: field of all outgoing emails.
User name | The username for authenticating against the SMTP server Default: <empty>
SMTP: Password | Password used to login to the SMTP server Default: <empty>
SMTP: Use sender's email address | If set the email address of the user sending the message will be used in the From field of the sent emails. If not the SMTP: Sender address will be used an the user's email address will only be used as Reply-To address.
SMTP: Allow attachments | If not set the Application Server will not send Attachments via this SMTP Server. Unset this if your SMTP server does not allow to send attachments, the Application Server will then be adviced to remove attachments from outgoing emails so that they can still be delivered


Snipplet_MR_ConnectionProperties

Last edited: 1/22/2018 9:14:06 AM

Connection parameter | Description
Name | This is the name for your connection. You may choose any name you want.
Server | This parameter tells MappRover where it can find the Application Server. The address can be given as DNS name like myserver.company.com or as an IP address like 210.134.29.12 or as just the hostname like Server001
Port | The port on which the Application Server is providing its HTTPS services. This is by default set to 443.
Instance | Name of the instance of the Application Server.


Snipplet_MsInfo32

Last edited: 10/5/2017 11:51:48 AM

To determine hardware and operating system details of a computer you can use Windows' MSINFO32 utility. MSINFO32 displays a comprehensive view of your hardware, system components, and software environment.


Snipplet_PasswordQualityRules

Last edited: 10/5/2017 11:51:48 AM

·Password must not contain the user name (case insensitive). If the username is less than three characters long, this check is skipped.

·Passwords must not contain the words Redbex, Server, User, Application (case insensitive)

·Passwords must contain characters from three of the following five categories:

oUppercase characters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)

oLowercase characters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)

oBase 10 digits (0 through 9)

oNon alphanumeric characters: ~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/

oAny Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.


Snipplet_SCApprovalColors

Last edited: 10/5/2017 11:51:48 AM


String comparison operators

Last edited: 10/5/2017 11:51:48 AM

Operator

Description

Equal

Tests for an exact but case insensitive match with the given comparison string.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Contains

Filters for all strings that contain the given comparison string.Comparison is done case insensitive.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Start with

Filters for all strings that start with the given comparison string. Comparison is done case insensitive.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Ends with

Filters for all strings that end with the given comparison string. Comparison is done case insensitive.

Wildcard characters are not supported, therefore user can search for special characters like %,[], ^, _.

Pattern

Filters for all strings that contain the given comparison pattern. Comparison is done case insensitive.

Wildcard characters are supported in the comparison pattern.


String comparison wildcards

Last edited: 10/5/2017 11:51:48 AM

Wildcard character | Description | Example
% | Any string of zero or more characters. | %Name% matches AB Name as well as AB Name CD as well as Name1 %Name% does not math AB Nam CD %Name does not math Name CD
_ | Any single character. | Feature _ matches Feature 1 as well as feature A
[] | Any single character within the specified range ([a-f]) or set ([abcdef]). | Feature [12345] matches Feature 1, Feature 3 but not Feature 9
[^] | Any single character not within the specified range ([^a-f]) or set ([^abcdef]). | Feature [^A-M] matches Feature M to Feature Z but not Feature A to Feature M


Snipplet_Support

Navigation: »No topics above this level«

Snipplet_Support.xml

Last edited: 10/5/2017 11:51:48 AM

Support for Redbex is available from:

Webpage : www.redbex.com

Email: support@redbex.com


Snipplet_UDEDetection

Last edited: 3/9/2018 10:27:46 AM

The character encoding detection built into Redbex is based on a port of the Universal Charset Detector of Mozilla. This charset encoding detection is able to detect the character encodings shown below

Detection of the character encoding is however in many cases non-deterministic, i.e. the character encoding of a file or a series of bytes can only be detected with a certain probability.

·UTF-8

·UTF-16 (BE and LE)

·UTF-32 (BE and LE)

·windows-1252 (mostly equivalent to iso8859-1)

·windows-1251 and ISO-8859-5 (cyrillic)

·windows-1253 and ISO-8859-7 (greek)

·windows-1255 (logical hebrew. Includes ISO-8859-8-I and most of x-mac-hebrew)

·ISO-8859-8 (visual hebrew)

·Big-5

·gb18030 (superset of gb2312)

·HZ-GB-2312

·Shift-JIS

·EUC-KR, EUC-JP, EUC-TW

·ISO-2022-JP, ISO-2022-KR, ISO-2022-CN

·KOI8-R

·x-mac-cyrillic

·IBM855 and IBM866

·X-ISO-10646-UCS-4-3412 and X-ISO-10646-UCS-4-2413 (unusual BOM)

·ASCII


Snipplet_Warning

Navigation: »No topics above this level«

Warning

Last edited: 10/5/2017 11:51:48 AM

This is the warning text.


%Text%

Navigation: »No topics above this level«

Snipplet_WhitespaceCharacters

Last edited: 10/5/2017 11:51:48 AM

Class | Members
Space Separators | SPACE (U+0020), OGHAM SPACE MARK (U+1680), MONGOLIAN VOWEL SEPARATOR (U+180E), EN QUAD (U+2000), EM QUAD (U+2001), EN SPACE (U+2002), EM SPACE (U+2003), THREE-PER-EM SPACE (U+2004), FOUR-PER-EM SPACE (U+2005), SIX-PER-EM SPACE (U+2006), FIGURE SPACE (U+2007), PUNCTUATION SPACE (U+2008), THIN SPACE (U+2009), HAIR SPACE (U+200A), NARROW NO-BREAK SPACE (U+202F), MEDIUM MATHEMATICAL SPACE (U+205F), and IDEOGRAPHIC SPACE (U+3000)
Line Separator | LINE SEPARATOR character (U+2028)
Other | CHARACTER TABULATION (U+0009), LINE FEED (U+000A), LINE TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), NEXT LINE (U+0085), and NO-BREAK SPACE (U+00A0).


Spring

Last edited: 10/5/2017 11:51:42 AM

This feature type represents a spring. It is platform for numerous other spring and water related feature types.

Characteristic | Note
Name | Spring
Path | \Hydrology
Feature type icon |
Feature type class | Platform
Spatial data support | Spatial support on feature (SSF)
Allowed spatial systems | All
Allowed Geometry types | All
Allowed contained feature types | In situ water characteristic (any number) Volumetric flow rate (any number)

Table 1: Characteristics of this feature type

Property structure for type specific feature data

Property, Property Collection Identifier | Description
Identifier Identifier | A (usually unique) string usually issued by some organization Property type: Text Default value: none Validation rule: none Display settings: single line
Location Location | Description of the location of the spring Property type: Text Default value: none Validation rule: none Display settings: multi line

Table 2: Properties and collections of the type specific feature data property structure

Property structure for type specific observation data

This feature type has no type specific observation data.


Statistical Values

Last edited: 10/5/2017 11:51:42 AM

This feature type is a generic feature type that is used as output feature type of the simple statistic calculation type. This feature type is usually the result of a calculation algorithm.

Characteristic | Note
Name | Statistic simple
Path | \Generic
Feature type icon |
Feature type class | Regular
Spatial data support | No spatial data support
Allowed spatial systems | N/A
Allowed Geometry types | N/A
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Minimum MIN | Minimum value of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Maximum MAX | Maximum value of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Mean AVG | Arithmetic mean of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Sum SUM | Sum of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Count CNT | Count of samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Median Med | Median of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Standard deviation Std | Standard deviation of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Modus Mod | Modus of all samples Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Lower quantil Q1 | Lower quantil Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5
Upper quantil 2 Q2 | Upper quantil Property type: Numeric Default Value: null Validation rule: none Display Options: Decimals: 5

Table 2: Properties and collections of the type specific observation data property structure


Synchronization with Active Directory

Last edited: 11/8/2017 10:15:02 AM

Redbex allows synchronizing users with the members of a specified Active Directory user group. If you plan to use Active Directory Authentication this will allow you to automatically give all users of that Active Directory user group access to the Redbex system.

To enable this functionality, the global settings under Active Directory group must be set.

Active directory synchronization can be manually triggered from the used client software or can be automated using the Active Directory Synchronization job type.

For the actual synchronization of users the Application Server will try to access the Active Directory Lightweight Directory Services (ADLDS) and will look up the members of the specified user group. For accessing ADLDS the Application Server will either use LDAP or LDAPS protocol, depending on your Global Settings.

For all Active Directory users in the specified Active Directory user group that are not locked and have a valid e-mail address set the Application Server will check if there is a Redbex user account with the same user name.

·If no, a new Redbex user account with that name will be created. All properties of the newly created account will be set to the properties found for the Active directory user. The authentication type for the newly created Redbex account will be set to Active directory

·If yes, all properties of the existing Redbex users will be modified to match the properties in the Active Directory. The Redbex user's authentication type will be set to Active directory.

If the Global setting Keep Local is not set all Redbex user accounts where no corresponding Active Directory group member can be found will be deactivated. If you want to work with a mixture of different authentication types (Active Directory and local) you shall therefore set the Global setting Keep Local to true.

The Manager account created during installation of the Redbex Application Server Database will never be deactivated by the synchronization irrespective of the Keep Local setting.

Synchronized information

When creating new Redbex users from an Active Directory user, or when updating existing users Redbex will automatically fill in the following data with the equivalent properties of the Active Directory user account.

·Username

·E-mail

·First name

·Middle name

·Last name

·Pre-nominal letters

·Description

·Phone number

·Cell phone number

·Address

·Company

·Department

·Position

Redbex will also set the following properties for users created during the synchronization process:

·Gender: Will be set to Undefined

·Authentication type: Will be set to Active Directory depending on the option with which synchronization is taking place

·Culture: Will be set to the culture of the user who performs the synchronization

·Publish extended information: Will be set to false


System privileges & permissions

Last edited: 11/8/2017 10:15:02 AM

System privileges define permissions users have on the system as a whole. The system privilege object is special in that there is only one system object and therefore no privilege object has to be selected when granting system permissions.

Permissions granted for the system privilege object can be thought of as global permissions. Table 1 lists the available system permissions.

System permissions are not inherited, and not transformed from other privilege objects. System permissions are transformed into other permissions on other privilege objects.

Permission name

No

Description, Actual actions granted

Manage users and user groups (0)

0

Create, modify and delete users and user groups. Reset user passwords, manage user password expiry.

Assign users to user groups, remove users from user groups.

All permissions on root views (1)

1

Create new root views.

This permission is transformed into all available view permissions on all root views and therefore through inheritance on all views.

This is a strong permission that has implications on the access to all data stored with features and observations. It is advised to use this permission sparingly.

Usually you should grant this permission only to users who really need to manage root views.

Modify system privileges (2)

2

Grant or revoke privileges with the system as privilege object.

Even if this permission is granted only privileges with permissions granted to the accessing user can be granted or revoked.

A user cannot revoke permissions assigned to himself.

Close user sessions (3)

3

Close the user sessions of other users and therefore kick them from the Application Server.

Modify global settings (4)

4

Modify the values of global settings.

Purge fully deleted messages (5)

5

Allows to purge all deleted messages that were deleted by all recipients and the sender.

This permission is only needed for users who administrate the system and do regular cleanups.

Read authentication log (6)

6

Permission to read the authentication log.

This permission is usually only needed by users who monitor the system for security issues.

Purge authentication log (7)

7

Permission to delete old entries in the authentication log.

This permission is only needed for users who administrate the system and do regular cleanups

Perform Distribution Server update (8)

8

Allows to fetch and install updates from the Distribution Server can be installed.

List all jobs (9)

9

List all jobs (in any job state) no matter who the job owner is.

Manage jobs (10)

10

Manage all jobs irrespective which user owns them.

Even if this system permission is not granted to a user, that user can still manage his own jobs (jobs started by this user).

This permission is usually only needed by users who want to monitor and manage the jobs and the load these jobs put on the system.

Purge archived jobs (11)

11

Delete the archived jobs i.e jobs that are finished.

Only needed by users who perform housekeeping on the Application Server.

Read user sessions (12)

12

Read the user session log.

Even if this permission is not granted a user can always read his own user session history.

Create user session when server is closed (13)

13

Create a user session (and therefore) logon to the Application Server even if server is closed.

Will only be needed by a few users, who want to perform housekeeping tasks while it is guaranteed that no other users are logged on.

List all approvals (14)

14

List all approvals.

Use privileged job priorities (16)

16

Create jobs with privileged priorities.

Purge features and observations (17)

17

[unused]

Purge user session log (18)

18

Purge the user session log.

Only needed by users who perform housekeeping on the Application Server.

List all observation alarms (19)

19

If this permission is granted the user can list all observation alarms (of all users for all features)

Acknowledge all observation alarms (20)

20

Acknowledge all observation alarms even if the user has no acknowledging obligation.

Grant this permission to users who should be able to clean up unhandled acknowledgement requests.

Manage personal stored job definitions (21)

21

Can create stored job definitions.

Stored job definitions that run at a regular schedule might put a huge load on the system. Therefore you can use this permission to allow only specific users to create stored job definitions.

Manage stored jobs definitions (22)

22

If granted allows a user to manage stored job definitions owned by other users.

Modify feature type privileges (23)

23

Grant and revoke privileges on feature types.

Even if this system permission granted the user can only grant or revoke privileges with permissions that he is granted himself.

Manage coordinate systems (24)

24

Create and modify coordinate systems that are used as reference system for features and observations with spatial support.

All permissions on feature types (25)

25

Is transformed into all available feature type permissions on all feature types.

Modify general text templates (26)

26

Modify general text templates, like the templates used for sending out login details via email.

List all Features (27)

27

If granted, the user can list all features.

Manage message forwarding rules (28)

28

If granted, the user can create and modify message forwarding rules for other users and global message forwarding rules.

Table 1: Permissions that can be granted to the system privilege object


Strain

Last edited: 10/5/2017 11:51:44 AM

A strain is a normalized measure of deformation representing the displacement between particles in the body relative to a reference length.

Characteristic | Note
Name | Strain
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | Point, Line
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection IDENTIFIER | Description
Strain STRAIN | Property type: Numeric Default Value: null Validation rule: none Display Options: ·Decimals: 5 ·Display unit: m/m
Temperature TEMPERATURE | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5

Table 2: Properties and collections of the type specific observation data property structure


Temperature

Last edited: 10/5/2017 11:51:44 AM

Represents the thermodynamic temperature of an object.

Characteristic | Note
Name | Temperature
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Temperature TEMPERATURE | Thermodynamic temperature Property Type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: none
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific feature data property structure


User groups

Last edited: 11/8/2017 10:15:02 AM

A user group is a named set of users. A user that is in this set of users is assigned to that group. One user can be assigned in any number of user groups. A user group can have any number of users assigned.

User groups can be structured tree-like in groups and subgroups. There is no system limit on the depth of that groups-tree. If a user is assigned to a subgroup he is implicitly member of all groups above and including that group in the group hierarchy. Figure 1 and 2 show an example of the membership propagation. Figure 1 shows the user to user group assignment as defined, figure 2 shows the effective user group membership.

The name of a user group must be unique within the hierarchy level of the user group, therefore the fully qualified name of the user group (it's path from the root group) is always unique. User groups can only be created and modified (including adding members to the group) by users with the system permission Manage users and user groups (0).

Figure 1: Example of membership propagation. The first image shows the group assignment, the second the second the actual memberships.


User management

Last edited: 11/8/2017 10:15:02 AM

Users and user groups are the basis for authentication, authorization, user specific settings and other things more. User management is the task of creating and modifying users and user groups.


View privileges & permissions

Last edited: 11/8/2017 10:15:02 AM

View privileges i.e. privileges that have a view as privilege object define permissions users have on a specific view. The effective permissions a user has on a specific view can be inherited from all parent views of that view, the system permission All permissions on root views is transformed into all available view permissions on all root views.

Note that only public views can be privilege objects, i.e. you cannot define privileges on private views. Private views inherit privileges from their parent view.

View privileges can not only be used to grant access to the views itself but also to the member features of the view (via transformed permissions). Granting permissions on features through view privileges is an extremely flexible and dynamic way to control access to features. When defining access to features by using view privileges you should mind following points:

·Since the members of views are determined by queries and features are not directly linked to views the permissions granted for features through view privileges can change whenever data of a feature changes. E.g. if you define a view that contains all features having an observation count greater 100 the view members might change when new observations are added to features. If that view defines privileges for accessing features those privileges will be granted to new members of the view automatically or removed from views that are not member any more.

·One feature can be member of any number of views and therefore the effect permissions a specific user has on a feature might include transformed permissions from several views.

·Privileges defined on views are inherited by all subordinate views of that view (on any level) I.e. the permissions granted through a privilege with parent view as privilege object will automatically be granted to all subordinate views. Therefore you can use view structure to further ease the work of defining privileges.

Table 1 and 2 list the permissions that are available when defining privileges that have a view as privilege object. Wile table 1 lists features that are effective on the view itself table 2 lists the permissions that are granted for views but are transformed to feature permissions for all members of a view.

Since some view permissions are transformed into feature permissions for all contained features and since the view members are cached it can happen that changes to view permissions that affect its members take some time to be effective.

Permission

No

Description

Modify view (0)

0

If this permission is given the user can rename a view change the view's filter conditions, change the view's presentation options etc.

This permission also includes the permission to delete a view and to change the permissions on the view.

List features (2)

2

If this permission granted the member features of of the view can be listed. Listing features allows reading the feature's identification data only, it does not implicitly give full read rights to all the features of the view.

If this permission is defined in a privilege for a view it is propagated to all subordinate views of that view.

List views (3)

3

If this permission is granted, user can list the subordinate views of the view and can read the view definition.

For a user to be able to list a root view this permission has to be granted on that root view.

Modify view privileges (4)

4

If granted the privilege subject can modify the privileges on that view. However the privilege subject can only add or remove privileges that it is granted itself.

Modify subordinate views (5)

5

This permission will be transformed to the Modify view (0) permission on all subordinate views. By itself this permission has not effect.

Table 1: Permissions that can be granted to view privilege objects

Permission | No | Description
Read features (100) | 100 | Same as the feature permission Read but applies to all features that are member of this view
Modify features (101) | 101 | Same as the feature permission Modify but applies to all features that are member of this view
Comment features (102) | 102 | Same as the feature permission Comment but applies to all features that are member of this view
Read observations (103) | 103 | Same as the feature permission Read observations but applies to all features that are member of this view
Modify observations (104) | 104 | Same as the feature permission Modify observations but applies to all features that are member of this view
Comment observations (105) | 105 | Same as the feature permission Comment observations but applies to all features that are member of this view
Observation Monitoring (106) | 106 | If this permission is given the user can create observation monitoring definitions on that feature.
Manage features (107) | 107 | Same as the feature permission Manage but applies to all features that are member of this view
Modify feature privileges (108) | 108 | If this permission is granted the privileges on the feature can be modified. Still the modifying user can only modify feature privileges (add or remove) with a permission that the modifying user is granted himself.
Abort approval workflows (109) | 109 | Same as the feature permission Manage approval workflows but applies to all features that are member of this view
Set approvals obsolete (110) | 110 | Setting started approval work flows to obsolete.

Table 1: Permissions that can be granted to view privilege objects and are transformed to permissions on all member features.


Volumetric Flowrate

Last edited: 10/5/2017 11:51:46 AM

Represents the volume of fluid passing though a given surface per unit time.

Characteristic | Note
Name | Volumetric flow rate
Path | \General
Feature type icon |
Feature type class | Regular
Spatial data support | Spatial support on feature
Allowed spatial systems | All
Allowed geometries | All
Allowed contained feature types | N/A

Table 1: Characteristics of this feature type

Property structure for type specific feature data

This feature type defines not property structure for type specific feature data.

Property structure for type specific observation data

Property, Property Collection Identifier | Description
Flow rate FLOWRATE | Amount of water delivered Property type: Quantity of type Volume / Time Default Value: null Default Unit: m³ / s Validation rule: Value ≥ 0 Display Options: Decimals: 2
Temperature Temperature | Represents the thermodynamic temperature Property type: Quantity of type Thermodynamic temperature Default Value: null Default Unit: °C Validation rule: Value ≥ -273.15 Display Options: Decimals: 5
Zero reading ZEROREADING | Used for marking the observation as zero reading observation Property type: Boolean Default Value: false Validation rule: none Display Options: none

Table 2: Properties and collections of the type specific observation data property structure