open-mastr doesn't translate category number to string value for columns where XSD doesn't markt the column as a restriction

[Simon-Will]

Description of the issue

When using Mastr().download(bulk_cleansing=True), I expect all catalog category values to be translated from the integer in the XML to the corresponding string in Katalogkategorien.xml. This doesn't work corretly for some columns:

• Netze.xml: Marktgebiet, Bundesland, Sparte
• EinheitenWind.xml: Hersteller
• Marktakteure.xml: Rechtsform, Registergericht

These are the ones I identified right now based on some heuristics. Maybe there are more that could be found from the values (cf. solution idea 3 below

Steps to Reproduce

1. Run Mastr().download(bulk_cleansing=True)
2. Query e.g. select distinct Sparte from Netze;. It results in [20, 21], while the desired result is ["Strom", "Gas"].

Ideas of solution

1. Ask BNetzA to fix their XSDs so that all catalog category columns are properly marked as <xs:restriction base="xs:short"> (short can also be int or byte)
2. In open-mastr, check the name of columns and compare them with the category names from Katalogkategorien.xml. If a column name has a match in the category names, treat the column as a category column. The matching cannot be made super strict because the category names sometimes have spelling errors ( Solaranlaege Anlagentyp) and the matching is often only rough e.g. column TechnologieFlugwindenergieanlagefromEinheitenWind.xmlbelongs to categoryTechnologie (Flugwind)`
3. We could also try to determine if it's a category from the value that we find in a column. If we only find integers (or comma-separated lists of integers), and many integers occur multiple times, then it's likely that it's a category column. The problem with this approach is that we want to get the table definitions from the XSDs, not the values in the XML files. It would complicate the current approach. And it's also a bit annoying to code.

Context and Environment

• Version used: Unreleased 73d1a3d
• Operating system: Doesn't matter
• Environment setup and (python) version: Doesn't matter
• MaStR version: 20260715

Workflow checklist

• I have checked the documentation and confirmed this issue is not already addressed there.
• I am aware of the workflow in CONTRIBUTING.md

[Simon-Will]

We should definitely do option 1: Asking BNetzA to fix their XSD. Then we can still decide if we want to pursue option 2 or 3; I'd argue not to, though, for reasons of not overcomplicating the import process.

I'm going to send an email to BNetzA.

[Simon-Will]

I sent the following email to BNetzA:

Sehr geehrtes MaStR-Team,

uns vom Projekt https://github.com/OpenEnergyPlatform/open-MaStR sind wieder ein paar Ungereimtheiten in den XSD-Dateien des MaStR-Doku-Downloads aufgefallen. Ich liste sie unten aufgeteilt nach Datei auf. Manche Probleme treten ähnlich in verschiedenen Dateien auf; es kann auch sein, dass es weitere ähnliche Probleme gibt, die uns bisher nicht aufgefallen sind. Wir würden uns freuen, wenn Sie die Probleme beheben können. (Oder erklären könnten, ob wir etwas falsch verstehen.)

Gerade die einheitliche Auszeichnung als Restriction im XSD hilft uns, zu erkennen, ob es sich um eine Spalte handelt, deren Werte in den Katalogwerten nachgeschaut werden müssen.

Freundliche Grüße
Simon Will

Netze.xsd

Restriction ohne enumeration

Sparte ist als xs:restriction ausgezeichnet, aber es fehlen die erlaubten Werte (20, 21).

Fehlende Restriction

Die Felder Marktgebiet und Bundesland sollten als xs:restriction ausgezeichnet sein, sind aber freie Felder.

EinheitenWind.xsd

Fehlende Restriction

Das Feld Hersteller sollte als xs:restriction ausgezeichnet sein, ist aber ein freies Feld.

Marktakteure.xsd

Fehlende Restriction

Die Felder Rechtsform und Registergericht sollten als xs:restriction ausgezeichnet sein, sind aber freie Felder.

Ertuechtigungen.xsd

Restriction ohne enumeration

Ertuechtigungsart ist als xs:restriction ausgezeichnet, aber es fehlen die erlaubten Werte:

<xs:element name="Ertuechtigungsart" minOccurs="0">
<xs:simpleType>
  <xs:restriction base="xs:short">
  </xs:restriction>
</xs:simpleType>
</xs:element>

Die folgenden Werte sollten vermutlich gelistet sein: 792, 793, 794, 795, 796, 797, 798, 1534.

Unechte Restriction

Die Felder EegMastrNummer, Leistungserhoehung und WiederinbetriebnahmeDatum sind als xs:restriction ausgezeichnet, sollten aber keine sein.

GeloeschteUndDeaktivierteMarktakteure.xsd

Falscher Typ?

MarktakteurStatus ist als xs:string ausgezeichnet, sollte aber vermutlich xs:short sein.

[nesnoj]

Thx @Simon-Will !
Quick thought: Should we have a warning for the users to point out input data problems when the XSD is flawed to avoid users to attribute it to open-mastr?
(as we have to expect the problems to occur in the future again..)

[Simon-Will]

@nesnoj, yes, that would make sense. Would you put it into the docs? Or try to detect the problem?