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.

Highlighting important rules

If you have editing permission for a protected area, open its rules in edit mode and click the "Important rule" icon emergency_home beside a rule. The selection is saved immediately; click again to remove it.

Selected rules appear above the full rule list when viewing the area. They also remain listed in their activity categories so visitors can find all rules for an activity together. Where possible, highlight no more than three rules so visitors can take them in at a glance. This is a recommendation, not a fixed limit.

The importance flag is also included in our API. Data users can use it to highlight important rules in their own applications, helping visitors find the most relevant information about an area faster and understand more precisely what to observe.

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 and place, allowed and forbidden rules must have non-overlapping seasonal periods. An allowance on paths and tracks can coexist with a ban on a narrower path category. A whole-area ban still excludes overlapping rules for the same activity.

RL-003 No simultaneous allowed and forbidden rules for the same activity and place

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

RL-004 Parent and child rules must have non-overlapping seasonal periods

A rule on main-activity level automatically applies to all included sub-activities. Parent and child rules may coexist in an area only if their seasonal periods do not overlap. Seasonal dates recur annually, include both boundary days, and may cross New Year. A rule without seasonal dates applies all year.

Different permissions, places, daily hours, weather conditions, comments, or approval states do not allow overlapping parent and child seasons. For example, a parent rule from 1 June through 30 September and a child rule from 1 October through 31 May can coexist. Starting the child rule on 30 September would create an overlap.

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 Path restrictions and narrower scopes

A broad path restriction and a stricter restriction can coexist when their activities or seasonal periods require both. Redundancy requires full seasonal coverage and sufficient regulatory strength. Daily times, weather and comments do not distinguish rules for validation.

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. Rules with the same activity, place and permission may coexist only in non-overlapping seasonal periods. Different daily times, weather conditions or comments do not permit duplicates. The result is independent of entry order.

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. Entering may use paths and tracks without being classified as a way-bound activity. Minimum width is supported for paths and tracks, narrow paths, and agricultural or forestry ways with allowed permission only.

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. For daily time ranges, both a start time and an end time are required, and they must be different.

RL-014 General path restrictions

Use entering, allowed and paths and tracks for general stay-on-path restrictions; use encouraged for voluntary rules. Paths and tracks includes narrow paths and agricultural or forestry ways without requiring public or designated status. The legacy off-path activity has been removed. General and locally scoped restrictions use entering on paths and tracks. Existing comments explaining local scope and other rule metadata are preserved.

RL-015 Only allowed or recommended rules on officially public streets and places

This spatial reference identifies the public streets and places on which an activity remains permitted despite restrictions elsewhere in the protected area. Using forbidden or, for voluntary categories, not recommended would reverse that meaning and incorrectly describe the public locations as the restricted part.

RL-016 Use one parent rule when all subactivities have the same rule

If the same rule applies to every subactivity, use one rule for the parent activity. Child rules remain possible when their conditions or comments differ. You can also keep separate rules if an individual subactivity needs an additional rule.

If a merge is possible, the editor shows a suggestion. Review it and confirm to save one parent rule.

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.