Archiv für den Monat: Januar 2013

Warum die “offenen Geodaten” von Baden-Württemberg eine Mogelpackung sind

Datum:       2 Kommentare  

“Baden-Württemberg gibt Geodaten frei”, so titelte beispielsweise Pro-Linux vor zwei Tagen. Schaut man sich das etwas genauer an, dann bleibt von dieser Aussage leider nur wenig übrig 🙁

Gut, die Maps4BW Rasterkarten stehen jetzt unter CC BY 3.0 zur Verfügung (leider derzeit nur in einem proprietären Format von ESRI[1]) und man darf daraus jetzt mit offizieller Erlaubnis durch abmalen von Rastergrafiken freie Vektordaten in (verglichen mit den Rohdaten) geringerer Qualität für OSM erzeugen!

Die eigentlichen Geodaten, aus denen diese Rastergrafiken erzeugt worden sind bleiben hingegen proprietär!

Wörtlich steht folgendes in den Nutzungsbedingungen des WMS:

Maps4BW liegen nicht offene Geobasisdaten zugrunde, deren Nutzung einer gesonderten Vereinbarung bedarf.

Die Rohdaten also, deren Erstellung zu einem Großteil vom Steuerzahler finanziert worden ist, stehen diesem also weiterhin nur unter einer teuren kommerziellen Lizenz zur Verfügung.

Sorry liebe Leute, aber das ist doch genau das worum es bei Opendata geht: Um die Freigabe von Rohdaten und eben nicht um irgendwelche hübsch aufbereiteten Rasterkarten! Bei Maps4BW handelt es sich zwar um eine recht brauchbare Webkarte, aber Anwendungen für die man Rohdaten benötigt (z.B. Routing oder Geocoding) kann man damit natürlich nicht machen.

Es wäre technisch erheblich einfacher gewesen Rohdaten zum download anzubieten statt daraus erzeugte Rasterkarten.

Es bleibt also festzustellen, dass die Freigabe von Geo-Rohdaten wohl auch unter einer Grün-Roten Regierung weiterhin nicht erwünscht ist.

Fazit: Opendata geht anders 🙁

[1] Der Firma ESRI, ist hier kein Vorwurf zu machen, deren Software kann die Daten problemlos auch in offenen Formaten liefern. Im Gegenteil ESRI verhält sich als Firma sogar ausgesprochen Opendata freundlich.

“git bisect” the perfect tool for knocking down bugs

Datum:    

The most annoying bugs are those of the “this did already work in the past” type.

Doing manual bisecting has also been an annoying task in the past. Especially when talking about Kernel bugs which will require frequent reboots.

Fortunately this step, while still somewhat time consuming, got much easier in recent times thanks to two very handy tools. One of them is git, the top-notch revision control system, the other one is virtualisation (virtualbox in my case).

So here is how I search the broken commit using theses tools:

Lets assume we have a problem which we discovered in kernel 3.7 and which did not appear in kernel 3.6.

First get a stable kernel tree if you do not already have one:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

Then issue the following 3 commands:

git bisect start
git bisect good v3.7
git bisect bad v3.6

Our source tree is now at a state where we must check if this kernel works or not. For this purpose I usually run Debian’s make-kpkg command which will build a debian package from a given kernel source.

Afterwards install this kernel in your virtual Linux system and reboot the VM.

Login to the VM and check if the bug is present there. If so issue a git bisect bad command, if not call git bisect good.

Repeat these two steps until git tells you exactly which commit did cause the problem.

Now all you need to do is mail the person responsible for the faulty commit 🙂

Kategorie: