The following page aims to support external parties who wish to transfer nature occurrence data to Naturdatabasen from an exising data repository. I.e. it is not intended for developers who wish to build up a new flexible data entry software that can support existing and future activity types.

Please refer to Swagger for reference when we refer to methods in the API. List of Swagger endpoints is here.

You will use the method POST/activities/import to create a new activity. But before you can do this, you need to investigate how to format your input object. This requires extensive configuration of your data.

Activate a new user

Before you can start to use the API, you need to activate your user. This is done by simply calling the method: GET https://nature-api.{environment}.miljoeportal.dk/account It is explained here: https://nature-api.miljoeportal.dk/openapi/#tag/Account/operation/GetCurrentUserAsync

Activity Type

Before you post an Activity, you need to find out what type of Activity Type it will belong to. You can find the list of Activity Types via the method GET/metadata/programs. What you need is the id of active children programs. Fx.

Activity Type Definition

Once you have found the id of the relevant activity type, you need to know how the activity type requires your activity object to be set up. Insert the id into the method https://nature-api.miljoeportal.dk/metadata/activity-types/{id} fx. https://nature-api.miljoeportal.dk/metadata/activity-types/510.

Other environments: UDV: https://nature-api.udv.miljoeportal.dk/metadata/activity-types/{id} TEST: https://nature-api.test.miljoeportal.dk/metadata/activity-types/{id} DEMO: https://nature-api.demo.miljoeportal.dk/metadata/activity-types/{id}

You will now be presented with a definition of the object structure required to post data.

In the following, we will only explain the attributes that an external data provider needs to succesfully post data. The definition in the API contains several attributes that developers - who merely wish to deliver data via the API - will not need to understand as they are only relevant when building up a user interface. These attributes are not explained below as we expect developers to just send null, ignore or exclude.

Activity Type Definition - Core Object Attributes

Contains general information of how data of activities of this activity type must be set up. Sometimes referred to as the AktDef.

• id: the activity type identifier. You will need this when adding the activity object to explain the definition being used.
• name: the name of the activity type.
• active: whether the activity type allows new activities to be added.
• isLine: activities require a main location geometry to be added. This attribute defines whether the geometry type of this location can be a line.
• isPoint: activities require a main location geometry to be added. This attribute defines whether the geometry type of this location can be a point.
• isShape: activities require a main location geometry to be added. This attribute defines whether the geometry type of this location can be a polygon.

Activity Type Definition - Sub Activity Object Attributes

Data in activities (akts) are grouped into sub activities (delakts) under which are then the registrations (regs). The definition of what data can be attached to a sub activity (delAkts) are configured on a Sub Activity Definition (delAktDefs).

• id: the sub activity type identifier. You will need this when adding the sub activity object to an activty to explain the definition being used.
• name: the name of the sub activity type.
• isMultiChoice: when true, it means an activity can consist of multiple sub activities of this sub activity type.
• isLocationVisible: when true, it means that a geometry object can be added to a subactivity of this type.
• isPoint: when true and when IsLocationVisible is true, it means that a Point geometry object can be added to a subactivity of this type.
• isShape: when true and when IsLocationVisible is true, it means that a Shape geometry object can be added to a subactivity of this type.
• isLine: when true and when IsLocationVisible is true, it means that a Line geometry object can be added to a subactivity of this type.
• isLocationRequired: when true and when IsLocationVisible is true, it means that the sub activity must include a geometry to be completed.
• vbvid: when it has a value, it means that this type of sub activity may only be added given a registration somewhere else in the activity has a specific value set. Read this section to understand VBV rules in detail.

Activity Type Definition - Reg Definition Object Attributes

Registration definitions (regDefs) are fields that collect data (regs) and that belong to sub activity definitions (DelAktDefs). The system supports 6 types of regDefs. Label, Number, Code, Text, Species, Nature Type, and Location. Label does not collect data but is purely meant to present information in collection forms. Typically used as sub section headers or explanatory help text.

• regTypeID: defines the kind of data that can be entered into the registration. There are 6 possible regtypes. 0: Label, 1: NumReg, 2: KodeReg, 3: TxtReg, 4: ArtReg, 5: NatTypereg. The regType also decides which attributes on a reg that will be accepted. When an attribute can only be used with certain regTypes, we will tag them below as fx "(RegType: 2,3)" meaning that this attribute is only used for KodeReg and TxtReg.
• id: the registration definition identifier. You will need this when adding the registration object to a sub activity object to explain the definition being used (RegType: 0,1,2,3,4,5).
• name: the name of the reg definition type (RegType: 0,1,2,3,4,5).
• unit: The unit of measurement for data collected (RegType: 1).
• codeListId: A reference to the list of possible codes that can be selected for a field (RegType: 2). You must use the method GET/metadata/codes in order to find out what the possible codes are for the list.
• speciesListTypeId: A reference to possible species that can be selected for this field (RegType: 4). You must use the method GET/metadata/species/search in order to find out what the possible codes are for the list. Use it with the ListTypeId value and IncludeChildren=FALSE.
• speciesTypeCodeListId: A reference to a code list of additional information that can be attached to a species registration (RegType: 4). The label to explain what data is stored in this field is specified in attribute typeCodeLabel. You must use the method GET/metadata/codes in order to find out what the possible codes are for the list.
• speciesAreaCodeListId: A reference to a code list of additional information that can be attached to a species registration (RegType: 4). The label to explain what data is stored in this field is specified in attribute arealCodeLabel. You must use the method GET/metadata/codes in order to find out what the possible codes are for the list.
• speciesFrequencyCodeListId: A reference to a code list of additional information that can be attached to a species registration (RegType: 4). The labels to explain what data is stored in this field is specified in attributes frequencyLabel and frequencyPostLabel. You must use the method GET/metadata/codes in order to find out what the possible codes are for the list.
• isFrequency: when true, it means that user can add an integer to specify the number of occurrences of the species that was seen (RegType: 4). This setting is never used at the same time as speciesFrequencyCodeListId as they serve the same purpose but in different ways. The attributes frequencyLabel and frequencyPostLabel may offer additional information as to how this value is measured.
• natureTypeListId: A reference to a list of nature types (RegType: 5). You must use the method GET/metadata/natureTypes in order to find out what the possible codes are for the list.
• isHidePercentShare: When set to FALSE, it means that we allow collection of a percentage value together with the nature type registration (RegType: 5). The percentage value typically represents the percentage of the activity geometry that is covered by the chosen nature type.
• isOptional: When set to FALSE, it means that this registration must contain a value before the activity is seen as completed (RegType: 1,2,3,4,5). When not completed, it will be impossible to change the status of the activity to submitted (using method POST/activities/{id}/status).
• isMultiChoice: when true, it means that this registration definition can consist of multiple registrations (RegType: 1,2,3,4,5). I.e. for a species field it means that user can attach multiple species registrations.
• minimum: the lowest allowed value (RegType: 1)
• maximum: the highest allowed value (RegType: 1)
• decimals: the highest number of allowed decimals (RegType: 1)
• defaultValue: a forced value for a specific field. Usually used on species fields that must contain a specific species (RegType: 1,2,3,4,5).
• vbvid: when it has a value, it means that this type of registration may only be added given a registration somewhere else in the activity has a specific value set (RegType: 0,1,2,3,4,5). Read this section to understand VBV rules in detail.
• isPinpoint: when set to TRUE, it means that this registration can contain pinpoint data, which consists of one ArtReg per species per pinpoint (RegType: 4). This setting overrides all other species specific settings.
• subActivityDefinitionId: a reference to the DelAktDef that the RegDef defines the field for.

VBV (Visible by Value) Rules

It is important that you understand VBV rules before you send in data, as it will restrict the delakts and regs that are allowed to be included in an activity. The logic of VBV rules are that regs (of certain regDefs) and delAkts (of certain DelAktDefs) are only allowed if the value of another reg in the activity is set to a specific value.

• id: the rule that is referenced on a regDef or a delAktDef
• name: the name of the rule. Generally does not contain useful information.
• active: whether or not the rule is in use. Currently not relevant as it is always true.
• regDefinitionId: we will look at the reg of this regDef to find the field whose value will decide whether the rule is applied or not.
• codeIds: any of the values that the referenced regDefinitionId field must have to be applied.
• visible: when true, it means that the field will be shown when the rule is applied (and else the field is hidden). When false, it means that the field will be hidden when the rule is applied (and else the field is shown).

Activity Objects

Once you have understood the definition of the activity type that you wish to submit to the API, you can post data to the database as activities using the POST/activities/import method.

We have generated a function you can call to get an example object. This object does not abide by the VBV and VVS rules, but does give an idea of how the structure of an activity for a specific ProgramID should look.

Insert the id of the context Program into the method https://nature-api.miljoeportal.dk/activities/import-json?programId={id} fx. https://nature-api.miljoeportal.dk/activities/import-json?programId=510.

Other environments: UDV: https://nature-api.udv.miljoeportal.dk/activities/import-json?programId={id} TEST: https://nature-api.udv.miljoeportal.dk/activities/import-json?programId={id} DEMO: https://nature-api.udv.miljoeportal.dk/activities/import-json?programId={id}

Below we explain the attributes of an activity object. We will only explain those necessary for external developers wishing to submit just basic activity objects. Attributes that are not explained below can be ignored.

Activity Core Object

The main information of the activity that you wish to submit.

• startDateTime: date and time that the activity took place.
• journalNumber: a string value when the activity has a related "journalnummer".
• noteText: custom text added to explain the data in the activity.
• programId: the id of the activity type that you wish to add data for. You choice will also decide what sub activities and registrations can be added to the activity.
• localGuid: add a custom GUID.
• purposeId: "Indsamlingsformål". Choose between: 1: Novana; 2: Kommunal besigtigelse; 3: VVM-analyse; 4: LIFE-projekt m.m.; 5: Andre myndighedsdata; 6: Øvrige data.

Location Object

Information of where the activity geographically has occurred.

• id: set to 0 when creating.
• name: a name of the location.
• shapeWkt: geometry of the location. ShapeWKT refers to the Well-Known Text (WKT) representation of geometric shapes.

Inventor Objects

Reference to the inventors (people performing the occurrence data collection work). To find the possible ids for this, you can use the method GET:/inventors with the user authority token as you will use to submit the activity.

• inventorIds: Array of inventors on the activity

subActivities Objects

What sub activity objects that can be added and how they are formatted is defined by the sub activity definition of the chosen ProgramID in the core object. Some sub activities are "multi", meaning that an activity can contain multiple objects with the same subActivityDefinitionId.

• id: set to 0 when creating.
• subActivityDefinitionId: the sub activity definition (delaktdef) that defines what data is contained in the sub activity (delakt).
• noteText: custom text added to explain the data in the sub activity.
• location: you can only add location data to a delakt when the delaktdef allows it. id: set to 0 when creating. name: a name of the location. shapeWkt: geometry of the location. ShapeWKT refers to the Well-Known Text (WKT) representation of geometric shapes.

codeRegs Objects

The data of regType=code added within the subactivity. The regDefinitionId must adhere to the allowed regdefs within the parent subActivityDefinitionId. When the regDef allows multi, you can also submit multiple objects with the same regDefId.

• id: set to 0 when creating.
• regDefinitionId: the reg definition (regdef) that defines what data is contained in the codeReg.
• codeId: the codeID from the applied code list. See the regDef for what the legal codeID values are.

natureTypeRegs Objects

What nature type data that can be added to the sub activity and how they are formatted is defined by the regDef definition of the sub activity definition. Some regDefs are "multi", meaning that the context sub activity can contain multiple objects with the same regDefinitionId.

• id: set to 0 when creating.
• regDefinitionId: the reg definition (regdef) that defines what data is contained in the natureTypeReg.
• natureTypeId: the natureTypeID from the applied nature type list definining the allowed nature types for this field. See the regDef for what the legal natureTypeID values are.
• natureTypePercent: When percentage is allowed on the natureTypeReg, you can add a value from 0 to 100 to this attribute.

numberRegs Objects

What numeric data that can be added to the sub activity and how they are formatted is defined by the regDef definition of the sub activity definition. Some regDefs are "multi", meaning that the context sub activity can contain multiple objects with the same regDefinitionId.

• id: set to 0 when creating.
• regDefinitionId: the reg definition (regdef) that defines what data is contained in the numberReg.
• value: the number added to the field.

speciesRegs Objects

What species data that can be added to the sub activity and how they are formatted is defined by the regDef definition of the sub activity definition. Some regDefs are "multi" or "pinpoint", meaning that the context sub activity can contain multiple objects with the same regDefinitionId.

• id: set to 0 when creating.
• regDefinitionId: the reg definition (regdef) that defines what data is contained in the speciesReg.
• speciesId: a reference to the species added to the field. See the regDef for what the legal species are.
• frequencyId: the codeID from the applied code list definining frequency of occurrence of the species. See the regDef for what the legal codeID values are.
• frequencyValue: A integer value when the regDef has specified that this attribute is applied for this regDef.
• areaCodeId: the codeID from the applied code list definining custom information of the species. See the regDef for what the legal codeID values are.
• speciesRegTypeId: the codeID from the applied code list definining custom information of the species. See the regDef for what the legal codeID values are.
• pinpoint: when the regDef is defined as a Pinpoint field, you will need to add one speciesReg per pinpoint location of the reg. The allowed values are numbers from 1 to 16.

textRegs Objects

What text data that can be added to the sub activity and how they are formatted is defined by the regDef definition of the sub activity definition. Some regDefs are "multi", meaning that the context sub activity can contain multiple objects with the same regDefinitionId.

• id: set to 0 when creating.
• regDefinitionId: the reg definition (regdef) that defines what data is contained in the textReg.
• value: the text added to the field.