Module 1: Learning the basic concepts of GeoDMS

(Difference between revisions)
 Revision as of 10:18, 8 April 2020 (view source)Jip (Talk | contribs)← Older edit Revision as of 10:25, 11 May 2020 (view source)Jip (Talk | contribs) Newer edit → Line 4: Line 4: Every data item has a [[domain unit]], which defines its entity. For example, we have a geographic data set with provinces in the Netherlands. The Netherlands has 12 provinces, so you could say that the [[domain unit]] has 12 rows, one row for each province. Within this [[domain]] we have information about each province: name, number of inhabitants, and geometry. Each information field is called an [[attribute]]: an [[attribute]] of the [[domain unit]] provinces. Every data item has a [[domain unit]], which defines its entity. For example, we have a geographic data set with provinces in the Netherlands. The Netherlands has 12 provinces, so you could say that the [[domain unit]] has 12 rows, one row for each province. Within this [[domain]] we have information about each province: name, number of inhabitants, and geometry. Each information field is called an [[attribute]]: an [[attribute]] of the [[domain unit]] provinces. - Each of those attributes holds information, and this can be numbers, text, or coordinates. We must tell GeoDMS what kind of information is being stored for each [[attribute]], this is called the [[values unit]]. + Each of those attributes holds information, and this can be numbers, text, or coordinates. However, we must tell GeoDMS what kind of information is being stored for each [[attribute]], this is called the [[values unit]]. - So, if we would see a dataset as a table, the number of rows (and its fixed order) are called the domain unit and the collumns represent attributes of that domain unit. + So, if we would see a data set as a table, the number of rows (and its fixed order) are called the domain unit and the columns represent attributes of that domain unit. + + You could also configure parameter values, these are special cases wherein the domain unit has just one row, and it can contain only one attribute. Thus, it contain only one value. =='''GeoDMS GUI lay-out'''== =='''GeoDMS GUI lay-out'''== Now we know that data needs to be configured in domain units and attributes. However, in most cases we would want to combine domains, or we simply want to structure data items. In such case we can uses containers, these are just like folders to hold all kinds of units or attributes and it has no domain of itself. Now we know that data needs to be configured in domain units and attributes. However, in most cases we would want to combine domains, or we simply want to structure data items. In such case we can uses containers, these are just like folders to hold all kinds of units or attributes and it has no domain of itself. - When you open the GeoDMS GUI you'll see that it uses a folder structure just like you are used to on Windows computers. Wherein folder can be either a container or a unit. + When you open the GeoDMS GUI you'll see that it uses a folder structure just like you are used to on Windows computers. Wherein a folder can be either a container or a unit. + =='''Calculation rules'''== - * Parameters + Configuring an item always consists of several components: - * Expressions + - * Properties + attribute<'value type'> name (domain) := expression; + And this could look like this: + attribute nr_of_inhabitant (provinces) := provinces/nr_of_inhabitants; - Configuring an item always consists of several components. + In GeoDMS, calculation rules are defined using expressions. For each unit, attribute or parameter you have to specify an expresssion. For example: - attribute<'value type'> name (domain) := expression; + + * Expressions + * Properties

Key concepts

Before we dig into the practical part, let's discuss some key concept which are fundamental to understanding GeoDMS and enables you to perform analyses.

Every data item has a domain unit, which defines its entity. For example, we have a geographic data set with provinces in the Netherlands. The Netherlands has 12 provinces, so you could say that the domain unit has 12 rows, one row for each province. Within this domain we have information about each province: name, number of inhabitants, and geometry. Each information field is called an attribute: an attribute of the domain unit provinces.

Each of those attributes holds information, and this can be numbers, text, or coordinates. However, we must tell GeoDMS what kind of information is being stored for each attribute, this is called the values unit.

So, if we would see a data set as a table, the number of rows (and its fixed order) are called the domain unit and the columns represent attributes of that domain unit.

You could also configure parameter values, these are special cases wherein the domain unit has just one row, and it can contain only one attribute. Thus, it contain only one value.

GeoDMS GUI lay-out

Now we know that data needs to be configured in domain units and attributes. However, in most cases we would want to combine domains, or we simply want to structure data items. In such case we can uses containers, these are just like folders to hold all kinds of units or attributes and it has no domain of itself.

When you open the GeoDMS GUI you'll see that it uses a folder structure just like you are used to on Windows computers. Wherein a folder can be either a container or a unit.

Calculation rules

Configuring an item always consists of several components:

```attribute<'value type'> name (domain) := expression;
```

And this could look like this:

```attribute<float32> nr_of_inhabitant (provinces) := provinces/nr_of_inhabitants;
```

In GeoDMS, calculation rules are defined using expressions. For each unit, attribute or parameter you have to specify an expresssion. For example:

• Expressions
• Properties