{"id":1629,"date":"2018-07-09T15:04:58","date_gmt":"2018-07-09T15:04:58","guid":{"rendered":"https:\/\/wetransform.eu\/?post_type=news-and-events&p=1629"},"modified":"2022-07-28T08:25:39","modified_gmt":"2022-07-28T08:25:39","slug":"xplangml-with-halestudio","status":"publish","type":"news-and-events","link":"https:\/\/wetransform.to\/de\/neuigkeiten-veranstaltungen\/xplangml-with-halestudio\/","title":{"rendered":"Create and Publish XPlanGML with hale\u00bbstudio"},"content":{"rendered":"

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<\/a>, 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.<\/p>\n

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.<\/p>\n

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<\/a>. 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.<\/p>\n

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<\/code>. One BP_Plan<\/code> can have multiple areas of validity, each of which is stored in an object called BP_Bereich<\/code>.<\/p>\n

<\/p>\n

\"Type<\/p>\n

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

BP_Plan and BP_Bereich joined to SpatialPlan<\/h2>\n

In this type-relationship, we join the types BP_Plan<\/code> and BP_Bereich<\/code> based on the following conditions:<\/p>\n

BP_Plan.id = BP_Bereich.gehoertZuPlan.href<\/code><\/pre>\n
Please note that hale studio automatically matches href<\/code> anchors to gml:ids<\/code> disregarding the #<\/code> if present.<\/p>\n
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<\/code>, which we all map to ordinance<\/code>.  For this purpose, we create an instance context<\/em> for each of the source dates, such as anderungenBisDatum<\/code>. We then simply rename the source date to ordinanceDate<\/code>, and assign the name of the source attribute as the ordinanceReference<\/code>.<\/p>\n
We also add references to different types of officialDocument<\/code>s. In particular, if the source data has a rasterBasis<\/code>, texte<\/code> and\/or begruendungsTexte<\/code>, we point to that by renaming that value to officialDocument.href<\/code>. The other mappings are straightforward. We directly re-use the gml:id<\/code> from the source for the target, as well as an INSPIRE localId<\/code>. name<\/code> becomes officialTitle<\/code>, rechtsstand<\/code> is reclassified to processStepGeneral<\/code>, and nummer<\/code> becomes alternativeTitle<\/code>.<\/p>\n
BP_Plan Groovy-retyped to OfficialDocumentation<\/h2>\n
With the main SpatialPlan<\/code> object having been created, we now need to create OfficialDocumentation<\/code> objects for various cases. The first is that BP_Plan<\/code> can contain multiple externeReferenz<\/code> references. For each of these, we create a OfficialDocumentation object. To do that, we use a Groovy Retype with this small script:<\/p>\n