You are using an old browser

We cannot guarantee the full functionality of the website in the Internet Explorer browser. Feel free to try another browser.
National geodata platform
Listen

For developers

To use the platform, there are APIs available for both consumers and producers. The APIs for retrieving information from the platform and for publishing information on the platform are described below.

The picture shows a process how you as a consumer or producer find or publish data from the geodata catalog.
Click on the image for a larger version.

Technical descriptions

Here you will find technical descriptions for all data sets, how reception works, the municipalities' charging and more.

For consumers, there are three APIs:

  • Search
  • Display and
  • Download,

For the manufacturer, there are two APIs:

  • Upload and
  • Update.

API for consumers

Search and Display is based on:

  • OGC standards,
  • OGC API for Features and
  • WMS.

In the search and display service, the reference object is a subset of the domain object, customized for finding information. It can therefore contain simplified and aggregated data. The purpose of the reference object is to find data in the platform. The entire domain object can then be accessed by download.

Geodata catalog Search - search for reference objects for domain objects and resources

Geodata Catalog View

Geodata Catalog Download - download domain objects and resources

Producer API

There are two APIs for publishing: Upload and Update. Upload is used to upload or register associated documents to the platform, so-called additional information. The Update API is then used to upload domain objects and publish them.

Geodata catalog Upload - load upp resources

Geodata directory Update - upload up domain object

Schemes for information models

The exchange format for domain objects is defined by technical schemas (JSON schemas) that reflect the current information model. These are used for validation of uploaded domain objects.

Overall Technical Information

Media Type

Each model version has its own media type to specify when the domain object is uploaded to the Geodata Catalog Update. The media type can be found in the link to the domain object in Geodata Catalog Search and in the Content-Type header from Geodata Catalog Download, so that clients know how to read the file correctly.

Additional information

In some domain models there is space to link associated documents in the object, e.g. detailed planning basis. The upload service can be used for this kind of additional information. These files will then be available to consumers via the Download Service. Each uploaded document is assigned a stable unique identifier to be inserted in the designated place in the domain object before it is submitted for publication.

Nothing but additional information may be uploaded or registered in Upload. If no published domain object refers to an uploaded file, it may be deleted.

Objects and sub-objects

Some information areas have several types of domain objects. In that case, they are arranged in a hierarchy, with a main object and a number of sub-objects. For example. in the information area detailed plan there is the main object "detailed plan" and the sub-object "plan provision", where an instance of a detailed plan can have several provisions.

All objects belonging to the same hierarchy must be together in the same file - one file per object tree. The root of the file is a GeoJSON Feature Collection, where each component is a Feature. An update of an object thus means that the entire file must be updated.

On each Feature, the attribute "id" should be set. If the attribute is set, the value must be the object identity. If the feature has a geometry, the attribute "bbox" should also be set.

Geometry

In domain objects, GeoJSON is used to describe the distribution of a phenomenon. However, the format has a number of limitations and peculiarities that the platform has rules for.

Geometries in the platform have metadata linked to them in a geometry model where the geometry itself is set in the attribute "position". In a GeoJSON Feature, it is instead advocated that the geometry be put in the attribute "geometry" in the root of the object. However, a Feature can only have one geometry, which is a problem for certain amounts of information. The platform therefore uses these rules to place the geometry: If the phenomenon can only have one geometry, "geometry" should be used and "position" should not be set. If the phenomenon can have several geometries, "geometry" should be set to zero and "position" should be used instead. Even if a certain instance only has one geometry, "position" must be used if the model allows several geometries. In this case, "geometry" is forced to zero in the JSON scheme.

GeoJSON normally only allows the reference system WGS 84. In an earlier draft of the standard, the attribute "crs" could be set in a geometry or Feature to specify a other reference system. However, this is NOT used by the platform. Instead, the reference system is specified in the attribute "coordinate systemPlan" (and "height system") in the platform's geometry model.

The geometry model allows the body and multi-body geometry types even if GeoJSON does not. A body is implemented with a MultiPolygon, where each surface is one of the sides of the body. All surfaces together must form a closed body. A multi-body is implemented with a GeometryCollection, where each included geometry is a body in the form of a MultiPolyon.

Support

Contact NGP Support.

Contents of this page may be automatically translated, we take no responsibility for the accuracy of the translation. Feel free to contact our customer support centre if you have any questions.

Read more about our website