Donnerstag, 7. Januar 2016

Mapnik 2.2 Inkompatibilitäten

Ich hatte letzte Woche ein Problem, daß mal wieder schön demonstriert:
  • was passiert, wenn man seinen Vorurteilen vertraut, statt die Dinge wirklich zu überprüfen
  • wie mühsam es sein kann, mit Open Source Produkten zu arbeiten
  • wie man viele Stunden Zeit verlieren kann, wenn beide Dinge zusammen kommen
Eigentlich wollte ich nur mal "kurz" eine Bayernkarte mit bereits vorhandenen Styles rendern. Sollte eigentlich kein Problem sein.



Leider wurde das Rendern mit folgender Fehlermeldung abgebrochen:

 mapnik.load_map(self.m, self.mapfile, True)  
 RuntimeError: Unable to process some data while parsing 'osm-wetter.xml':  
 * node 'MaxScaleDenominator' at line 0  

Was war das?

Vermutlich war irgendetwas mit 'MaxScaleDenominator' nicht in Ordnung. Besonders aussagekräftig war die Meldung ja nicht.

Es gab folgende Definition:


1
2
3
<!ENTITY maxscale_zoom7 "<MaxScaleDenominator>6500000</MaxScaleDenominator>">
<!ENTITY minscale_zoom7 "<MinScaleDenominator>3000000</MinScaleDenominator>">
<!ENTITY maxscale_zoom8 "<MaxScaleDenominator>3000000</MaxScaleDenominator>">

Das bedeutete meiner Meinung nach, daß die Regionengrenze um die es hier ging im Zoomlevel 7 und 8 dargestellt wurde. Das schien mir in Ordnung zu sein. Der Code stammte nicht von mir und meine Erfahrung mit Mapnik 2.0.1 sagte, daß dort ja alles problemlos funktioniert hatte.

Ich hatte also keine Idee warum das Rendering nicht funktioniert. Das bedeutete: Suche die Nadel im Heuhaufen!

Naja, schien ja nicht so kompliziert zu sein. Ich durchleuchtete das Rendering. Irgendwie gelang es mir dann, eine minimale Version meiner Styles zu rendern. Aber sobald ich wieder meine Styles mit 'MaxScaleDenominator' einband, lief nichts mehr. Ich überprüfte die Makroersetzung explizit. Las mich nochmal genau in die Styleverarbeitung von Mapnik ein - leider eine sehr spröde und fragmentarische Doku. Schon das allein kostet viel Zeit, denn man muß ja verstehen, was da steht.

Als das alles nichts brachte, beschloß ich die Daten zu validierten. Dazu baute ich die in den Styles verwendeten Datasets mit Quantum Gis nach. Das funktioniert alles tadellos. Ich war mir also sicher, meine Daten waren OK und auch die Abfragen in den Styles. Es mußte also irgendwas an den Styles nicht funktionieren.

Also warf ich nochmal einen genauen Blick auf diesen Code und nach einiger Zeit hatte ich die entscheidende Idee: Verwende keine Makros sondern schreibe das XML ohne Makroersetzung!

Das führte zu folgendem Code:

<Style name="selected_region_border">
   <Rule>
     <MaxScaleDenominator>6500000</MaxScaleDenominator>
     <MaxScaleDenominator>3000000</MaxScaleDenominator>
      <LineSymbolizer stroke="#8fb5c9" stroke-width="4" stroke-linejoin="round"/>
    </Rule>
</Style>

Sofort war klar: Das ist UNSINN!

'MaxScaleDenominator' gibt an bis zu welcher Auflösung ein bestimmter Style gerendert wird. Es ist natürlich nur eine Grenze sinnvoll. Wenn man mehr als eine Grenze angab, wurde das in Mapnik 2.0.1 toleriert. Ab Mapnik 2.2 hatte wohl ein Entwickler beschlossen, das als Fehler zu behandeln. Das kann man gut verstehen, aber der Fehler wurde vermutlich als solcher nicht ausgegeben sondern erst in irgendeiner Schicht darüber abgefangen und dann die oben zitierte Fehlermeldung ausgegeben, die nicht viel aussagt.

Jetzt lief alles wie geschmiert. Das freute mich. War aber anderseits auch bitter. Es hatte mich einige Stunden Suche gekostet. Eine eindeutige Fehlermeldung durch Mapnik wie z.B. "MaxScaleDenominator darf pro Style nur einmal verwendet werden" hätte mich in kürzester Zeit zu dem Fehler geführt.

Ich will nicht sagen, daß so etwas in Closed Software nicht passieren kann. Aber die Wahrscheinlichkeit ist vermutlich deutlich geringer. Wenn mehrere Entwickler getrennt voneinander Code schreiben und sich in Sachen Fehlerbehandlung aufeinander verlassen, passieren genau solche Dinge, wenn die Kommunikation mal nicht so gut ist. Gerade wenn die Kommunikation hauptsächlich aus irgendwelchen Commit-Kommentaren oder EMails besteht, ist das Risiko von Problemen besonders groß.

Keine Kommentare:

Kommentar veröffentlichen