ObjectLand permits specifying unlimited number of group conditions for features of one type.
Let's examine a simple example of specifying two group conditions for features of the type “Building”. In the demo database the table “Building Certificates” which has the fields “Number of Storeys” and “Is Residential?” is linked with this feature type. Let's formulate conditions using these fields:
condition of group 1:
the building is residential and has one or two storeys;
condition of group 2:
the building is residential and has not less than two and not more than five storeys.
For any one-storeyed residential building condition of group 1 is true, that is, this building belongs to group 1 just as any three-storeyed residential building belongs to group 2.
To which group do two-storeyed residential buildings belong? Both group conditions are true for them. In this case the order in which conditions are checked becomes important. ObjectLand arranges all the specified group conditions in the form of a list and allows the user to change the order of conditions in this list, if necessary. Condition check for every feature is performed from the beginning of the list to the end and is finished as soon as one of the checked conditions turns out to be true. The remaining conditions for this feature are not checked. Thus, none of the features can belong to two groups simultaneously.
In the example described above two-storeyed residential buildings will fall into one group with one-storeyed buildings, because the condition of group 1 is true for them. If the order of groups is changed, two-storeyed buildings will fall into one group with three-, four- and five-storeyed buildings.
The described rules of checking group conditions may seem to be insecure to use, since basing on the order of conditions it is rather difficult to predict in which group the feature will fall. Actually, there is no such a problem because group conditions can always be formulated in such a way that no feature could satisfy two conditions at the same time. In this case the order of conditions in the list does not play any role.
All the features for which at least one of the group conditions is true make up a standard group “True” with respect to the whole filter condition for the present feature type.
Among the features of the present type there may be such features for which none of the specified group conditions is true (and at least one of the conditions is definitely false). Such features make up the standard group “False” with respect to filter condition. In described example the group “False” includes, firstly, all the buildings having more than five storeys and, secondly, all non-residential buildings.
Finally, there is the third possibility. For some features it may be impossible to check this or that group condition due to absence of table data about this feature required for the check. Such a situation may arise in two cases:
there is no linked record in the table for the present feature;
there is a linked record, but the field of this record used in the group condition has an empty value, that is, it is undefined.
Checking group conditions for a particular feature according to the list, the system ignores the conditions for the check of which there is not enough data. If all group conditions are ignored for this reason, that is, it is impossible to say if this condition is true or false for all of them, the system attributes the present feature to the standard group “Undefined”.
Thus, if N different group conditions are specified for some type of features, all the set of features of this type will be partitioned in N+2 non-intersecting groups (some of which may be empty, that is, not containing features):
Groups 1, 2, … , N containing features for which the appropriate group condition is true. A set of all these groups is called the standard group “True”.
The standard group “False” containing features for which no group condition is true and at least one condition is false.
The standard group “Undefined” containing features for which it is impossible to check any group condition due to absence of data.
For every N+2 groups it is possible to specify a specific displaying style distinguishing it from other groups. Besides, for each group it is possible to indicate if features of this group should be displayed at all.
The name “standard group” reflects the fact that these groups exist for any filter, they cannot be removed (unlike the groups determined by the user).
When creating a filter group the system assigns names to them: <Group 1>, <Group 2>, … <True>, <False>, <Undefined>. The user can rename groups giving them descriptive names which reflect the meaning of the condition for every group. For example, it is possible to create a filter by value of number of storeys in buildings specifying the following groups: “Not higher than three storeys”, “From four to seven storeys” and “From eight to ten storeys”. In this case it will be logical to rename the group “True” to “Not higher than ten storeys”, the group “False” – to “Higher than ten storeys”, and the group <Undefined> – to “Number of storeys is unknown”. The filter as a whole can be named “By Number of Storeys”.
It should be noted that simple conditions based on spatial characteristics of features always have a definite value, either true or false. Undefined conditions are impossible in this case, because all data used to evaluate the condition are contained in the feature's coordinates which are certainly known. Therefore, if at least one filter group comprises only spatial conditions, then the <Undefined> group will be empty for this feature type.
 |  |
