Combine_data - ObjectVision/GeoDMS GitHub Wiki
Relational functions combine_data
- combine_data (combined_domain, a_rel, b_rel, ...)
combine_data(combined_domain, a_rel, b_rel, ...) results in an attribute with index numbers to the combined_domain argument, combining the values of the data items a_rel, b_rel and further: one relation per factor of combined_domain.
The first argument combined_domain is usually made with a combine function.
The combine_data function results in an attribute with an index to combined_domain for each element of the domain of a_rel, b_rel and further, with as values unit the first argument of the function (combined_domain) and as domain unit the domain unit of the relations.
The last relation varies fastest, as in the numbering of combine: for combined_domain := combine(A, B, C), relations with the index numbers a, b and c give ((a × #B) + b) × #C + c. combine_rel and first_rel(x_rel) to sixteenth_rel(x_rel) compute the relations back.
Since GeoDMS 20.24.0 combine_data is an operator that knows the factors of the combine that made combined_domain, and uses them:
- Each relation is checked against the factor at its position: its values unit must have the value type, metric, projection and spatial reference of that factor. A literal, such as the 0 in
combine_data(X, 0, id(P)), passes. - That check compares value types, not which unit it is. Two factors of the same value type, such as two uint32 domains without a metric, can still be swapped without notice, so keep the relations in the order of the factors.
- The index numbers are taken within the ranges of the factors, so
first_rel(combine_data(X, a_rel, b_rel))isa_relagain. - A null in any relation gives null, and so does a value outside the range of its factor.
Until then combine_data was a function in the prelude that computed the index from the values units of its arguments alone, without looking at the factors of combined_domain. A relation of another value type than its factor was accepted, and so was a number of relations that differed from the number of factors; both now stop with an error at the item that calls combine_data. A value outside the range of its factor gave the index of another combination, and now gives null.
When combined_domain is not made by a combine function, for instance a unit read from a storage, combine_data still computes as before, from the values units of the relations, without a check.
- unit combined_domain with value type from the group CanBeDomainUnit.
- attributes a_rel, b_rel, ... with value type from group CanBeDomainUnit.
- The domain units of the relations must match (or be void, as that of a parameter).
- One relation per factor of combined_domain. When some of the factors are themselves combines, one relation per factor of those is also accepted, see below.
- The values unit of each relation must match the factor at its position in the combine with which combined_domain has been defined.
7.131
O(n) where n = number of elements in the domain of the relations. Single pass computing the combined index from the input relations.
Since GeoDMS 20.24.0 combine_data takes one relation per factor directly:
unit<uint32> ABC := combine_unit(A, B, C);
attribute<ABC> ABC_rel (domain) := combine_data(ABC, domain/A_rel, domain/B_rel, domain/C_rel);
A combine of combines takes one relation per factor, or one per factor of the inner combines; both give the same result:
unit<uint32> BC := combine_unit(B, C);
unit<uint32> A_BC := combine_unit(A, BC);
attribute<A_BC> A_BC_rel (domain) := combine_data(A_BC, domain/A_rel, combine_data(BC, domain/B_rel, domain/C_rel));
attribute<A_BC> same_rel (domain) := combine_data(A_BC, domain/A_rel, domain/B_rel, domain/C_rel);
unit<uint32> NHCityYear := combine(NHCity, YearDomain);
attribute<NHCityYear> NHCityYear_rel (Adomain) := combine_data(NHCityYear, NHCity_rel, YearDomain_rel);
| NHCity_rel | YearDomain_rel | NHCity | Year | NHCityYear_rel |
|---|---|---|---|---|
| 0 | 0 | Amsterdam | 1995 | 0 |
| 0 | 1 | Amsterdam | 2005 | 1 |
| 1 | 1 | Haarlem | 2005 | 3 |
| 2 | 0 | Alkmaar | 1995 | 4 |
| 2 | 1 | Alkmaar | 2005 | 5 |
ADomain, nr of rows = 5
| nr_1 | nr_2 | NHCityName | Year |
|---|---|---|---|
| 0 | 0 | Amsterdam | 1995 |
| 0 | 1 | Amsterdam | 2005 |
| 1 | 0 | Haarlem | 1995 |
| 1 | 1 | Haarlem | 2005 |
| 2 | 0 | Alkmaar | 1995 |
| 2 | 1 | Alkmaar | 2005 |
domain NHCityYear, nr of rows = 6
| NHCity/name |
|---|
| Amsterdam |
| Haarlem |
| Alkmaar |
domain NHCity, nr of rows = 3
| YearDomain/Year |
|---|
| 1995 |
| 2005 |
Yeardomain, nr of rows = 2
Until October 2026 the column NHCityYear_rel of the first table read 0, 3, 4, 2, 5, a numbering in which the first factor varies fastest. combine_data has the last factor varying fastest, as the table of NHCityYear shows.
- combine_rel, for the relations back to the factors
- full configuration example: Overlay versus Combine data