Data and rule logic

Digitize the Planet e.V. (DtP) pursues the goal of providing rules for recreational use in protected areas in machine-readable form. For this purpose, a data standard was developed that structures legal provisions while making them usable for digital applications. The data is recorded with georeferences and can therefore be integrated into modern applications such as planning tools or navigation services. To ensure consistency, clarity, and data integrity, a clear rule logic was defined. This does not always involve a complete 1:1 representation of legal documents. Instead, rules are simplified and structured so that they are understandable and practical for digital systems and users. In certain cases, this also means that not all detailed provisions are adopted.

Example: If a general entering ban exists, only this ban is recorded and additional detailed rules are omitted.

Rule composition

A rule consists of three central components:

1. Activity

The activity is selected from a standardized category list based on legal requirements and common recreational activities.

Example: "Water activities" as a parent category for surfing, boating, or diving.

2. Spatial reference

Rules generally apply to a georeferenced area (for example, a protected area), but their content can be limited to specific parts of that area.

Example: Cycling is only permitted on designated paths within the protected area.

3. Permission

Permission describes whether an activity is:

• forbidden
• allowed
• for voluntary categories: recommended or not recommended

In principle, the system works with a ban logic. Restrictions are interpreted as "only permitted under certain conditions".

Note: Rules currently always apply to the full extent of the respective spatial reference. A restriction to individual, concrete elements (for example, specific paths) is currently not possible.

Core principles

Bans

An activity is generally prohibited, possibly with reference to specific spatial categories.

Example: Entering off paths is prohibited.

In contrast, restrictions define the cases in which an activity is only permitted under specific conditions.

Restrictions (permission with conditions)

An activity is only permitted under certain conditions. These conditions can be time-based, spatial, or situation-dependent.

Example: Cycling is only permitted:

• on unpaved agricultural roads
• wider than 2 m
• from 01.05. to 31.08.
• in dry weather

Important: For one activity, bans and restrictions must not be defined at the same time. A restriction automatically acts as a ban for all cases that are not explicitly permitted.

Main and sub-activities

Rules for a main activity and its sub-activities cannot be mixed in conflicting ways.

Season overlap logic

Contradictory rules with overlapping time periods are not permitted.

However, consecutive seasonal regulations are allowed, for example:

• 01.05.-31.08.: Cycling allowed
• 01.09.-31.10.: Cycling only allowed on designated paths
• 01.11.-30.04.: Cycling prohibited

The system supports this automatically: When creating new rules, remaining time periods are adjusted automatically.

Exception: A seasonal entering ban can be combined with activity-specific bans that apply all year.

Ongoing Data Quality Monitoring

Our objective is to ensure the long-term accuracy, precision, and reliability of our data. At the same time, full traceability of all content must be guaranteed. For this reason, we conduct regular automated validation processes complemented by manual, sample-based quality reviews. These include technical integrity checks, consistency analyses, conflict detection within rules, verification of referenced resources, and the identification of outdated or missing content.

Please do not be surprised if we occasionally contact you regarding inconsistencies or potential errors in the data. We understand that such inquiries may sometimes require additional effort. However, we consider this part of our service and a shared commitment to maintaining a consistently high level of data quality and ensuring that all information remains accurate and up to date.

Detailed rule logic

RL-001 No additional rules with a general entering ban

If a general entering ban applies to an area, no additional rules may be defined. All activities are already implicitly excluded. Additional rules would not add value and could lead to misunderstandings.

RL-002 No restrictions when an activity is already generally forbidden

If an activity is generally prohibited, no additional restrictions may be defined for it. A restriction represents conditional permission. A simultaneous prohibition leads to a logical contradiction.

For the same activity, either a prohibition or a restriction (permission under conditions) can apply. A combination of both variants for the same activity is not permitted.

RL-003 No simultaneous allowed and forbidden rules for one activity

For one activity, mutually exclusive or semantically redundant permission states must not be created at the same time.

RL-004 No mixed rules between main and sub-activities

A rule on main-activity level automatically applies to all included sub-activities. Redundant detail rules can lead to conflicts or inconsistencies.

RL-005 No mixed general and specific designated-path rules

General designated-path restrictions and equivalent specific designated-path restrictions must not coexist.

RL-006 No mixed designated-path scope and narrower path subtype scope

Designated-path/place scope and additional narrowing to path subtypes must not coexist for the same activity context.

RL-007 No contradictory dog rules

The rule 'Dogs on a leash' is a special case because it represents a specific restriction within the general activity 'Dogs'. Conflicting combinations are prevented to avoid contradictions between the general dog rule and the specific leash rule. Therefore, it is not possible to prohibit dogs and create a leash requirement at the same time.

RL-008 No duplicates

Rules with an identical combination of activity, spatial reference, and permission must not be stored multiple times. An exception only applies when the rules have different temporal validity ranges.

RL-009 No restrictions for the whole area

Restrictions always define that an activity is only permitted on specific subareas of a protected area. It is therefore excluded to define a restriction, or an allowed rule without limitation, for the entire area. Such a rule would imply that the activity is allowed throughout the whole area. In the data logic, this corresponds to the default assumption that, for activities available on the Digitize Platform, what is not prohibited is generally allowed. It therefore does not require explicit storage.

RL-010 No voluntary rules for official protected areas

Voluntary rules are only valid for voluntary protected-area categories and not for legally regulated protected areas. This ensures that only legally accurate rules are stored, not subjective desired rules. This is already blocked by the platform in the entry form.

RL-011 No way-related rules for non-way-bound activities

Rules with a way-related spatial reference may only be created for activities that actually take place on ways. For non-way-bound activities such as swimming or camping, a way reference is factually incorrect and therefore blocked.

RL-012 No minimum-width values in unsuitable rule contexts

Minimum path-width values are only allowed when they are semantically valid: as a restriction on way-related places. For area-wide rules or prohibitions, a width value is not allowed because it has no concrete meaning there. minimum_path_width must be between 0.5 and 5.0.

RL-013 No incomplete datasets

Every rule must contain all required components: activity, spatial reference, and permission. This also applies to optional attributes when they are used: for seasonal validity, both a start date and an end date are required.

Verification and publication

VP-001 Manual verification on save for high-impact rules in large protected areas

For large protected areas (> 5 km²), new or changed high-impact bans are not published automatically. Once such a rule is created, the Digitize Team manually verifies and activates it. If necessary, we contact you for clarification.

VP-002 No public visibility without a legal document

Rules are only published when a legal document is available for the protected area. If no legal document is provided, the rules remain hidden both on the website and in the API. This ensures that all published rules remain verifiable and transparent.