News > xplangml
News' image preview

INSPIRE is not the only open standard for spatial information in Europe, obviously. In Germany, a new standard has been made mandatory in several states in the past year. This standard is for all kinds of planning data, ranging from regional plans to land development plans. The standard is called XPlanung, with the current version of the encoding being called XPlanGML 5.1, and it is mandatory for all companies submitting plans, and for all municipalities publishing plans.

There are several challenges when creating compliant plans, among them the fact that many plans are still only available as scans in PDF, TIFF or PNG format. Actual geodata is then usually limited to a few attributes and a polygon that describes the perimeter of the plan area.

One approach that the community around XPlanung has discussed in detail is to align INSPIRE Planned and Existing Land Use to XPlanung (and vice versa). This alignment was described in the form of a 218-page document. On that base, when you implement one, you can get the other standard for free. However, the length of that document already gives an indication about the complexity of the transformation. This complexity stems both from the size of the XPlanung standard, which covers all types of spatial plans, and from the numerous codelists employed in the source and target models.

For this article, we will only investigate how to map the most common type of plan, a land development plan, to INSPIRE Planned Land Use. In XPlanung, such plans are called BP_Plan. One BP_Plan can have multiple areas of validity, each of which is stored in an object called BP_Bereich.

INSPIRE is not the only open standard for spatial information in Europe, obviously. In Germany, a new standard has been made mandatory in several states in the past year. This standard is for all kinds of planning data, ranging from regional plans to land development plans. The standard is called XPlanung, with the current version of the encoding being called XPlanGML 5.1, and it is mandatory for all companies submitting plans, and for all municipalities publishing plans.

There are several challenges when creating compliant plans, among them the fact that many plans are still only available as scans in PDF, TIFF or PNG format. Actual geodata is then usually limited to a few attributes and a polygon that describes the perimeter of the plan area.

One approach that the community around XPlanung has discussed in detail is to align INSPIRE Planned and Existing Land Use to XPlanung (and vice versa). This alignment was described in the form of a 218-page document. On that base, when you implement one, you can get the other standard for free. However, the length of that document already gives an indication about the complexity of the transformation. This complexity stems both from the size of the XPlanung standard, which covers all types of spatial plans, and from the numerous codelists employed in the source and target models.

For this article, we will only investigate how to map the most common type of plan, a land development plan, to INSPIRE Planned Land Use. In XPlanung, such plans are called BP_Plan. One BP_Plan can have multiple areas of validity, each of which is stored in an object called BP_Bereich.

Type relationships to map XPlanung to INSPIRE

The basic structure in the INSPIRE model is easy enough: There is a SpatialPlan as the main feature type that has a set of OfficialDocumentation objects linked to it that provide legal and other information. We will thus first create the SpatialPlan, and then create all the OfficialDocumentation objects.

BP_Plan and BP_Bereich joined to SpatialPlan

In this type-relationship, we join the types BP_Plan and BP_Bereich based on the following conditions:

BP_Plan.id = BP_Bereich.gehoertZuPlan.href

Please note that hale studio automatically matches href anchors to gml:ids disregarding the # if present.

After doing so, the main information we can map is the set of dates that are present in the source type. There are 13 different date values available in BP_Plan, which we all map to ordinance. For this purpose, we create an instance context for each of the source dates, such as anderungenBisDatum. We then simply rename the source date to ordinanceDate, and assign the name of the source attribute as the ordinanceReference.

We also add references to different types of officialDocuments. In particular, if the source data has a rasterBasis, texte and/or begruendungsTexte, we point to that by renaming that value to officialDocument.href. The other mappings are straightforward. We directly re-use the gml:id from the source for the target, as well as an INSPIRE localId. name becomes officialTitle, rechtsstand is reclassified to processStepGeneral, and nummer becomes alternativeTitle.

BP_Plan Groovy-retyped to OfficialDocumentation

With the main SpatialPlan object having been created, we now need to create OfficialDocumentation objects for various cases. The first is that BP_Plan can contain multiple externeReferenz references. For each of these, we create a OfficialDocumentation object. To do that, we use a Groovy Retype with this small script:



What this script does is to emit an object that contains an ID created in a reproducible manner - using the URL of the reference as input string to generate a UUID.

We then assign the remaining required values to the created objects, such as the INSPIRE Identifier namespace.

BP_Bereich retyped to OfficialDocumentation

The feature type BP_Bereich can also contain references to various documents. We thus retype BP_Bereich to OfficialDocumentation and use the information from BP_Bereich in a straightforward mapping:

Transform XPlanGML BP_Bereich to INSPIRE OfficialDocumentation

Throughout these mappings you will note the use of a log of Assign (Bound) functions. These assign a constant value to the target if the source attribute is present for a given transformed object.

BP_TextAbschnitt retyped to OfficialDocumentation

Finally, A BP_Plan can also contain explicit structured text objects. We also want to bring these BP_TextAbschnitt over to OfficialDocumentation and retype them as well. Much like before, the actual mapping of the properties below is straightforward and only requires Renames, Assigns and a Assign (Bound) function:

Transform XPlanGML BP_TextAbschnitt to INSPIRE OfficialDocumentation

Exporting XPlanGML and conclusion

To export the transformed INSPIRE GML, you do not need to do anything special. You can just use the normal “Export Transformed Data” option.

It is also possible to export XPlanGML from hale studio. For this, you need to create custom data export based on the generic XML writer. This is easily done in just a minute following these steps:

  1. Go to File –> Export –> Create Custom Data Export…
  2. Pick “XML (Custom Root Element)” and click “Next”
  3. Give your custom export configuration a name (without spaces, e.g. xplangml_51) and a description
  4. Choose the correct XML root element; here, this will be XPlanAuszug, and click “Next”.
  5. Choose other settings such as formatted number output, CRS handling and pretty printing, and click “Finish”. You can now export source or transformed data as XPlanGML.

The transformation project is available via haleconnect.com. You can either download it directly from the web interface or in hale studio. In both cases, you need a (free) haleconnect account.

We will continue to build out this alignment and create others for XPlanung and INSPIRE. Let us know if you have any input or would like to get engaged in this activity!

Happy transforming!

(more)