Data and rule logic

The goal of Digitize the Planet e.V. (DtP) is to provide rules for recreational use in protected areas in machine-readable form. A data standard was developed to represent the relevant legal provisions for recreational activities in protected areas in a structured way. To ensure dataset integrity and avoid redundancies and contradictory information, a dedicated rule logic was designed to meet these requirements.

This does not always mean an exact 1:1 representation of a legal document. To keep the data usable for digital platforms and understandable for human users, rules are simplified to preserve the necessary legal meaning. For example, if a general entering ban exists, this is stored as the only rule, even if the legal document contains additional detailed rules. This principle is described in more detail in the specific validation sections below.

Rule composition

To keep our data as precise and flexible as possible, each rule consists of three components:

• Activity
• Spatial reference
• Permission (forbidden, allowed, or, for voluntary categories, discouraged/encouraged)

Rules currently always apply to the full extent of the defined spatial reference. For example, a rule such as 'Cycling is forbidden on paths' generally applies to all paths within the protected area. Targeted restrictions to individual paths are currently not possible.

Core principles

Bans vs. restrictions

In legal provisions, we generally distinguish between bans and restrictions. In our data model, this distinction is represented through permission. For the same activity, either bans or restrictions are allowed. A restriction acts as an implicit ban for all cases that are not explicitly allowed.

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 ranges generally cannot be created. Seasonal rules can coexist if their date ranges do not overlap. Exception: A seasonal general 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 are allowed. All further activities are implicitly excluded by the general entering ban. Showing additional rules does not add informational value and may even cause confusion.

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

If an activity is generally forbidden, no restriction can be defined for that activity. Restrictions require a general allowance and only refine it spatially. A combination of ban and restriction for the same activity is always a logical contradiction.

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.

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 define that an activity is only allowed on specific subareas. A restriction for the whole area is therefore excluded. Such a rule only restates the legal default and 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.

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.