Import Marktstammdatenregister data for wind power plants

Communities Deutschland (Germany)
,
1

Following the discussion in this post

I’d like to suggest an import of data for german wind power plants from the "Markstammdatenregister” (MaStR) data set, which was approved as data source for OSM 2023. The import is currently in the planning stage and I’ll link the proposal later on (probably tomorrow or so). Basically the dataset contains every detail of every generator/power plant that feeds energy into the german power grid.

As the dataset is really large and rather complex I’d like to limit myself on improving data quality for already mapped wind power plants onshore.

I’ve written some custom software to download and process the data before importing.
The idea would be to first import the ref:mastr (uniq id of all generators in DE)
based on matching already mapped OSM objects and confirming these with some existing tags where possible. After that importing of missing tags like power values, height etc will be very easy either automatic or by hand. The goal is not to cover everything, but to improve data quality where it’s reasonably “easy” to do so without to much headache. Improving already existing tags e.g. with minor differences will probably need further discussion later on.

From ~29k currently active wind turbines (>300kW) in the MaStR and about ~31k mapped wind turbines in OSM, I was able to generate ~26.5k matches within 50m based on coordinates. Then I looked at how many of these matches can be confirmed with existing tag, e.g. the ones which - I think - could readily be imported without conflicts:

  • ~ 3k based on turbine model
  • ~ 3.6k based on rotor diameter
  • ~ 3.5k based on hub height
  • ~4.5k based on power values in kW
  • ~6k based on power values in MW
  • ~2k based on start_date
  • all of the above, minus duplicates: ~12.6k
  • ~12k based on manufacturer
  • all of the above minus duplicates: ~15.7k
  • without any ~11k

These numbers are with strict identity matching, which I am working on relaxing for some of the tags like e.g. model, which should improve numbers significantly. Matching on manufacturerer only I’d like to avoid where possible because that might not be very robust e.g. with repowering.

There are cases where OSM tags are formatted in non-standard ways, like date or wrong seperators in power values etc. And then there are many different spellings of the same manufacturer. I’m currently looking at how to "correct or rather improve these either manual or automatic before importing, depending on the impact it might make on confirming matches.
ref:mastr seems to increase in use recently and in preparation I’d also rename where ref:MaStR was used instead.

The code is available on Github. This includes some generated maps where the matches (from the above example) can compared visuallly to OSM data. Feel free to have a look at these maps, the code or some other part of the data set and report any issues. And of course I’ll very much welcome help with this import later on, too.

If there are some questions already feel free to aks, such that I can include it in the writeup or we can discuss here.

3 Likes
2

I am not shure this is a good idea. Importing non geo-feature based Datasets has turned to be a long standing issue in the past.

Look up Import, Discussion and decades of removal of “geoDB” tags/data.

It can not and never will be a one shot import but a long standing burden to maintain the data. I agree that adding a unique identifier to be able to link the datasets is a good idea - besides that i am sceptical.

Flo

1 Like
3

While I understand these concerns, the wide acceptance for manual edits/additions based on the same data source shows the relevance it has gained. So the question of how to maintain this data already exist. Instead in my opinion the question to aks is wether we should just accept outdated/incomplete data or should we try to improve the data quality?
Right now this is all done manually, which wouldn’t be necessary for many cases that could be covered. For cases which don’t allow an import with high confidence this would remain as is.

Obviously any import would only include relevant tags e.g. like in the wiki generator:source=wind Maybe this wasn’t clear from above, as the dataset contains many many additional entries which I agree are absolutely irrelevant.

I would also assume this dataset to be very stable, as already built facilities for electricity generation/conversion typcially don’t change if at all after the fact, apart from their regular lifecycle.

Aditionally my tool is already able to show cases where manual editing would provide the most value, e.g. recently built/demolished turbines.

4

The point is that over the last 15+ years we have imported data, we then in the long run had to remove.

Look at tons of tags of the original Tiger import in the US, The GeoDB tags on places, in Germany we imported the TMC data points.

It all first went bit rotting, then someone decided it made sense to remove it, now its still bit rotting and over decades will get removed.

This is why i am concerned about “yet again” importing some non spatial dataset.

1 Like
5

First of all I would disagree, that this is a non spatial dataset, as it contains for each object coordinates and associated values matching properties of a real world object.

Searching for “MaStR” in recent changesets shows ~1.5k results in the last 30 days, meaning this data is (since the waiver was given in 2023) steadily being integrated, be it automatic or not. I’ve already come across parts of the community which basically focus on only importing this data manually to update existing or adding newly built ones. Because of this I find it especially hard to imagine how (if done carefully) importing missing tags on existing objects would do any additional harm.

On the other hand not maintaing this data (which is very tedious doing manual obviously) creates other problems. Try searching for “Windpark XZY” and one of the first results are websites which just aggregate OSM data, which is often incomplete.

But I’m also happy to focus on importing ref:mastr for now - which would already be the hardest work done in helping others to improve on that.

2 Likes
6

I see an important difference to past imports like TMC or geoDB. Wind turbines are physically well-defined objects: they are fixed at a specific location and their core characteristics rarely change. This makes them fundamentally different from many non-spatial or administrative datasets that caused problems in the past.

I consider the matching and import of ref:mastr=* to be reasonable. I do not see this as creating “data junk” comparable to geoDB, where often dozens of loosely related tags were added. In this case it is a single, well-defined identifier, which can be very useful.

Having ref:mastr=* in OSM could later enable systematic comparisons to identify where OSM data is missing, outdated, or incorrect. That alone already provides value, even if no further tags were imported automatically.

From my perspective, importing generator:output:electricity=* also makes sense. This tag is already used in practice and has clear benefits, for example in applications like OpenInfraMap.

Similarly, height=* seems useful, especially for 3D visualizations and potentially for aviation-related navigation use cases.

For the remaining tags, I do not have a strong opinion. Personally, I would not make much use of them, but if there is a demonstrated real-world benefit and the import is done carefully, I would not object to their inclusion.

Overall, I think a limited, well-scoped import focused on identifiers and a small set of clearly useful physical attributes is very different from the problematic imports we have seen in the past.

5 Likes
7

I have mapped a couple of wind turbines and my own preset is

power=generator
generator:source=wind
generator:method=wind_turbine
generator:output:electricity=* 
generator:type=horizontal_axis
rotor:diameter=*
height:hub=*
ref=*
operator=*
manufacturer=*
model=*
start_date=*
ref:mastr=*

I don’t know if all of these tags make sense and are used by anyone but this are the data often available even without access to the MaStR (which has not been an approved source until 2023) and they provide a comprehensive idea about the object.

:+1:

3 Likes
8

Interestingly I just found this relation, where someone used another id from the MaStR the so called “MaStR-Nummer der technischen Lokation” from Netzanschlusspunkte und Lokationen of the website. This is seemingly used as a reference to group the individual wind generators into the wind farm in the dataset. Using this you can easily find out which plants belongs together.

There are few more occurences of this.

This would be worth thinking about, as this could happily live in the ref:mastr space and would eliminate the confusion of having to tag multiple SEExxx together on the acutal wind farms.

9

Some nodes already have the correct SEExx tagged in either ref, note, description, name etc. (e.g “description”~”MaStR”). I have retagged some of them manually. This also helped to improve coverage for ongoing tests wether false positives are a problem.

First results look good - Fairly small radius (e.g. <25m) and matching on some existing properties show very low false positives if at all (well below 0.1%, compared to ~30k overall wind generators currently in OSM).

This confirms my idea to first import (in multiple rounds with increasing radius) (near) matches on either start_date, model, etc. The order would still need to be determined. After that importing cases where the location is near exact, regardless of matches might be worth to look at, because quite a view plants especially from >>5 years ago are only mapped very bare without any additional details.

I need to make some further improvments on the code, do some more testing such that the proposal I’ll then write is clear on the procedure.

Exactly, if the link is established once it can always be used later on.

1 Like
10

Some inisights on existing tagging I’d like to share after some more code testing and a handfull of small individual reviewed changes to get a better feeling on what would be worth to look at before proceeding to write everything up.

There are a ~250 cases where Exxx..xxxx (commonly tagged as ref:EEG, sometimes ref:eeg in bavaria :roll_eyes:) is just tagged as plain ref=Exxxx

It might be worth to convert these to ref:EEG. Mistakes are almost impossible as nobody would tag something like this 33 char ref without intention on a generator. Matching would then be a bit easier and later on ref:EEG could potentially be deprecated (well it’s not even documented properly anyway right now …) in favour of the more flexible ref:mastr. Same thing applies to solar plants, but could of course be left out if need be.

Also the already deprecated manufacturer:type is still somewhat in use (a few hundred). It looks like there is still new data appearing using this deprecated tag. I’ll try to investigate and contact authors. Maybe there are still templates using this. Anyway, I think similar reasoning as above for (at least) a one time re-tag could apply here.

Then there’s cases where the life-cycle was just tagged descriptive like “description”=abgebaut”, note=”dismantled” etc without using the proper prefixes, which makes identifiying objects that can safely be deleted when they’re not visible any more on satelite images just unnecessary cumbersome. I will edit these manually whenever I come across it, as this is (luckily) very rare.

Happy to hear feedback if this sounds plausible (only applied to DE), the first two could either be done manually with JOSM etc or (preferably, especially if potentially being repeated) using the existing bot-framework.

Otherwise the code for importing ref:mastr is almost ready, conflation doesn’t make any problems in local tests. Any ideas on how to potentially split it up are welcome. Maybe by state? The thing is I’d like to still keep the changsets separated by which existing tag was used to confirm the match. Otherwise it would be very confusing to understand if this is all mixed together.

1 Like
11

:+1:

By state seems reasonable. If it’s not too cumbersome, you could further split it into (current or historical) “Regierungsbezirke”.

12

Frage am Rande: Wieso wird in diesem Thema im deutschen Forum, das ausschließlich Anlagen in Deutschland mit Eintrag im deutschsprachigen MaStR betrifft, englisch kommuniziert?

13

Das frage ich mich auch. Kann es sein, daß der Beitragsfaden aus dem Bereich “General talk” kam?

14

Das kam daher, weil mein Code und Notizen sowie die Dokumentation der relevanten Seiten im Wiki etc. überwiegend auf Englisch ist.

Können aber gern auf Deutsch wechseln wenn das gewünscht ist.

1 Like
15

Das ist sicher für viele einfacher. Es gibt zwar das Übersetzungstool, aber so super das auch ist, muss man trotzdem Post für Post übersetzen und das macht das Topic dann schon unübersichtlicher.

2 Likes
16

Guten Abend.

Mal eine datentechnische Frage zum Thema, von jemanden (=ich), der in dem Thema nicht drin steckt…

Vorgeplänkel…

  • Mein Heimat-Bundesland Brandenburg stellt ja Standorte der Windkraftanlagen bereit; downloadbar auch über unseren Geobroker [Anmerkung: Stand jetzt gerade IT-Wartungsarbeiten]. Da man zum Download auch die AGB’s des LGB bestätigen muß, betrachte ich das als nutzbare Daten, hatte ich schon mal thematisiert

So… Dieser Datenbestand beinhaltet auch ein Shape mit den WKA’s…
Dieses hat neben (ich sag mal durchaus erfassungswürdige Randdaten) auch:

  • Feld Bst_Nr (Betriebsstättennummer), Anl_Nr (Anlagennummer) und (sollte nach Doku so sein) ein Feld WKA_ID (Formaler Identifikator aus Bst_Nr und Anl_Nr)
  • letzteres WKA_ID setzt sich also ausBst_Nr und Anl_Nr zusammen.
  • Ist z.B. Bst_Nr = 10652920000 und Anl_Nr =4001 so ist WKA_ID=106529200004001 {vgl. Doku dieser Daten}

Frage: wie ist dieser Markenstammregister-ID zusammengesetzt?
Ist das genau so?
Ist das anders?

Sven

17

Es gibt im Marktstammdaten-Register (das gibt’s ja erst “relativ kurz”, seit Anfang 2019) diverse verschiedene id’s, bisher habe ich die Folgenden schon (vereinzelt) in OSM-Daten (sei es als ref, description usw) identifiziert.

Mit Länge 33, Ziffern, Buchstaben sowie manche Sonderzeichen erlaubt:

  • Exxx - Anlagenschlüssel EEG, wird nach Netzbetreiber-Prüfung allen Anlagen die nach dem EEG einspeisen zugeteilt. Kann lange dauern bis die auftaucht, wurde/wird bisher
    als ref:EEG getaggt.

Mit Länge 15, nur Ziffern, laut Wikpedia bestehend aus 3 Buchstaben Präfix für die “Funktion” + Versionsziffer + zehn zufällige Ziffern + Prüfziffer am Ende

  • EEGxxx - EEG Marktstamm-Nummer der zugehörigen EEG-Einheit (veraltet, sowie ich das verstehe)

  • SEExxx - Marktstamm-Nummer der Einheit, die bekommt JEDER im Register registrierte Generator (bzw. Bauabschnitt bei PV-Anlagen) einzeln. Die ist als ref:mastr im Wiki dokumentiert.

    SELxxx - Marktstamm-Nummer der Lokation, damit wird ein “Einspeise-Punkt” bei Kraftwerken bzw. Wind/Solarparks identifiziert

  • SGExxx - Marktstamm-Nummer der Genehmigung, mMn irrelevant

  • ABRxxx - Marktstamm-Nummer des Anlagen-Betreibers, selbsterklärend für osm mMn irrelevant

  • KWKxxx - Marktstamm-Nummer der KWK - nur für Anlagen mit Kraft-Wärme-Kopplung

Mit Länge 14, nur Ziffern

  • Axxx ?? finde ich auf die schnelle nicht mehr was das war, aber irgendwo wurde die auch schon mal getaggt, wenn ich mich recht erinnere.

Die vollständige Dokumentation (es gibt noch ein paar weitere speziellere Nummern die aber für nicht relevant halt … ) hier als Download, im Abschnitt 5.5 gibt’s die Zusammenfassung für die verschiedenen Erzeuger. Datendownload | MaStR

Bisher konnte ich nur bei der ersten Exxxx festellen, dass die - zumindest manchmal - als Block vergeben wird z.B. E4045001SCHOENEWALDEWERGZA1822021 - ..22025
Eine nennenswerte Bedeutung bwz. Beziehung untereinander haben die mMn also, wie man es für ids auch normal kennt, nicht.

Der Vorteil der SEExxx ist für osm, dass die universell für alle Erzeuger existiert und auch schon z.B. während der Bauphase verfügbar ist. Außerdem wäre es (wurde irgendwo schon kurz erwähnt) in bestimmten Fällen auch möglich eine der ggf. besser passenden Nummern im selben Namens-Raum ref:mastr zu nutzen.

Grüße

18

Uhi… Achtung: fast 2,8GB an Daten…

erst mal habe ich den Datendownload abgebrochen… ich überschlafe die Sache erstmal…

Sven

1 Like
19

Das ist außerdem noch encoded, also mit Platzhaltern etc. Nutzbar ist das dann ein Vielfaches davon. Ich benutze dieses tool https://github.com/OpenEnergyPlatform/open-MaStR damit kann man nach Energieträger filtern und bekommt eine sql-lite Datenbank, mehr als die 10 Zeilen Beispiel-Code aus der Doku braucht man nicht kopieren, oder mein verlinktes Repo klonen ;)

20

Es steht außer Frage, das so eine WEA alleine schon aufgrund ausufernder Bürokratie unzählige Nummern hat. Es dürfte jedoch überhaupt nichts bringen, die alle in OSM zu hinterlegen.

Wir hatten bereits im parallel laufenden Topic Marktstammdatenregister die Nummern besprochen, die für WEA in OSM erfasst werden bzw. sinnvollerweise erfasst werden könnten. z.B.

Als ref:
Die eigentliche Anlagen-ID, unter der die Anlage auch in der Decentralised Energies Emergency Platform (DEEP, früher WEA-Anlagenregister) aufgeführt ist und meistens die in großen Lettern über der Turmtür prangt. Diese beinhaltet im Normalfall eine Herstellerkennung und eine überschaubare Nummer. Vestas Anlagen z.B. beginnen mit einem V und lauten z.B. V246456. Das ist nach meiner bisherigen Erfahrung die einzige Nummer, die vor Ort erkennbar ist (aber auch nicht immer, vor allem bei älteren Anlagen fehlt sie manchmal).

Als ref=mastr:
Die MaStR Anlagennummer (SEExxx) als direkten Link zum MaStR, indem sämtliche relevanten Anlagedaten abgelegt sind.

Idealerweise würde die vorgenannte Anlagen-ID im MaStR im Feld “Anzeige-Name der Einheit” stehen, ist aber meistens nicht der Fall, weil dieser Name vom Anlagenbetreiber selber vergeben wird und meistens ein völlig nichtssagender Name dafür erfunden wird, der ansonsten nirgendwo auftaucht und für OSM nicht relevant ist.

Mehr als diese 2 Nummer sind m.E. nicht notwendig, da alle relevanten Anlagedaten im MaStR abgelegt sind, aber wenn jemand unbedingt noch irgendeine regional oder lokal vergebene Nummer dranhängen will, sollte er dafür nicht ref=* verwenden, sondern eine anderen Key ref:*=*, damit in ref nicht die unterschiedlichsten Nummer landen und den Key damit nutzlos machen.

Das gilt speziell für KWK-Anlagen, die gerne aus mehreren BHK bestehen.

Die einzelnen BHK haben jeweils eine eigene MaStR-Anlagennummer und können, falls sie vor Ort lokalisiert werden können, jeweils als power=generator mit ref:mastr=SEExxx getaggt werden.

Die KWK-Anlage hat eine zusätzliche Anlagennummer KWKxxx. Die Gesamtanlage kann also mit power=plant und ref:mastr=KWKxxx getaggt werden.

Da passt das MaStR-Schema zufällig genau zu unserem Taggingschema :grinning_face:.

Beispiel für so eine Anlage siehe hier:

OpenStreetMap

3 Likes