Why development of German OSM Carto style is currently stuck.

I am the Maintainer of the German Style OSM Carto fork and operator of http://tile.openstreetmap.de for a couple of years now. Usually I try to follow upstream releases as fast as possible to make sure that the fork keeps as close to upstream as possible.

However, back in March OSM Carto v5.0.0 has been released which requires a reimport of the osm2pgsql database. As doing this is a lot of work for my small two-server setup maintained by a single person I decided to combine this reimport with a new Approach for map localization I have been thinking about for some time. The code is designed for the new osm2pgsql Flex Backend introduced by Jochen Topf in February. Unfortunately I did not look closely enough at the Flex Backends documentation. I missed the fact, that the get_bbox()function is currently not available on relations which would force me to disable localization for relations. I decided against doing this for now in the hope that Jochen will add this missing feature to his code soon. If this situation will persist till the end of the year I will likely have to think about another solution, but for now we will unfortunately just have to wait.

Der Verschwörungsmythos vom sogenannten Großen Austausch

Verschwörungsmythen, wie man Verschwörungstheorien besser nennen sollte, weil es sich dabei selbstverständlich nicht um falsifizierbare Theorien handelt sondern um Dogmen, deren Wahrheit für die Anhänger außer Frage steht, haben in Coronazeiten Hochkonjunktur.

Der Grund scheint zu sein, dass manche Menschen wirkliche Probleme damit haben zu akzeptieren, dass es viele Dinge gibt, die zufällig passieren und die gerade nicht irgendwelchen menschlichen Plänen folgen.

Nichts mit dem Thema Corona hat indes der Verschwörungsmythos vom „Großen Austauch“ zu tun, der im Umfeld der Neuen Rechten beliebt ist. Mit diesem bin ich diese Tage in Form eines anonymen, persönlich an mich adressierten Briefes in Berührung gekommen.

Dem Absender war es immerhin 80¢ und einen Briefumschlag Wert mir dieses Pamphlet ohne Absender persönlich zuzusenden. Mangels Absenderadresse daher also nun meine Reaktion in öffentlicher Form.

Ich Frage mich ernsthaft was der anonyme Absender als Reaktion darauf meinerseits erwartet. Sollte ich jetzt, weil mir meine selektive Wahrnehmung vielleicht sagt, dass ich Zitat: „in der Fußgängerzone“ zu viele Menschen mit Migrationshintergrund sehe, eine antipluralistische und menschenfeindliche Partei wie die AfD wählen?

Wer sich mit Geschichte ein wenig auskennt, der wird wissen, dass gerade Vermischung neue menschliche Kulturen hervor- und bestehende vorangebracht haben. Dass von Austausch keine Rede sein kann werde ich hier nicht weiter begründen. dazu finden sich für den geneigten Leser bereits viele seriöse Quellen im Netz.

Als nur ein gutes Beispiel von vielen sei der Blog des Beauftragten gegen Antisemitismus des Landes Baden-Württemberg genannt. Diesem habe ich im übrigen ganz im Sinne des Verfassers eine Kopie des Briefes weitergeleitet.

Schade, dass sich der Absender nicht zu erkennen gegeben hat. Ich wüsste nämlich allzu Gerne was Menschen dazu treibt solchen offensichtlichen Unsinn wie diesen Verschwörungsmythos auch noch für bare Münze zu nehmen. Wie alles bei den sogenannten Neuen Rechten ist natürlich auch dieser alles andere als neu.

Wie man die Qualität von Fernradwegen mit Hilfe von OSM und Brouter berechnet

Vor vielen Jahren habe ich mich in diesem Blog schon einmal über die Absurdität von ausgeschilderten Fernradwegen ausgelassen. Was sich seither geändert hat ist die Tatsache, dass es das Openstreetmap basierte Routingprogramm, dass ich mir damals gewünscht habe inzwischen gibt. Die Rede ist von Brouter. Eine Software von Arndt Brensched, die es sowohl als App für Android als auch als Web-Planungstool gibt.

Nun lese ich heute einen Tweet von Hanno Böck, der sich ebenfalls über solche Fernradwege beschwert.

Nachdem ich wie üblich bei solchen Fragen das Brouter Tool empfehle wird mir klar, dass Brouter vermutlich genau das was Hanno gern hätte leisten kann. Was man gerne hätte wäre ja so eine Art Qualitätsfaktor für Radrouten.

Nach einer kurzen Kommunikation mit Arndt wird klar, dass das ganz einfach ist. Man konfiguriert das Routingprofil für Trekkingrad so um, dass man die Behandlung der Fernradwege umkehrt.

Aus folgender Anweisung:

else if ( is_ldcr ) then 1

macht man einfach diese hier:

else if ( not is_ldcr ) then 10000

Nun deaktiviert man noch die Höhenkosten und fertig ist der Engine zur Berechnung der Qualität von Fernradwegen.

assign consider_elevation = false

Je kleiner der durchschnittliche Kostenfaktor im Brouter-Web um so besser ausgebaut ist die Radroute. Wer die beschriebenen Änderungen nicht selbst machen möchte kann sich unter https://home.geggus.net/score.brf das geänderte Profil runterladen.

Die deutsche Corona Warn App und die Datensparsamkeit

Leider gibt es in der Smartphonewelt nicht wirklich die Option ähnlich wie beim Desktop PC ein datensparsames Betriebssystem wie Debian GNU/Linux zu verwenden.

Die zweitbeste Lösung besteht darin ein Android auf Basis des Android Open Source Projekts (AOSP) wie LinageOS zu verwenden.

Leider ist man auch in diesem Fall in der Praxis trotzdem oft dazu gezwungen das proprietäre Paket GSF von Google zu installieren, weil viele Programme dieses benötigen.

Ohne Anmeldung im Play-Store bei Google ist man aber trotzdem zumindest pseudonym unterwegs und kann die meiste Software über freie Alternativen wie FDroid und Aurora-Store installieren.

Nicht so bei der Corona Warn App. Diese beschwerte sich erst mal über fehlende Aktualität des Play-Stores obwohl dieser installiert (aber nicht konfiguriert und deaktiviert) ist.

Ich war also erst einmal nicht in der Lage die App auf einem solchen datensparsamen System zu verwenden. Das ist Schade, weil bei der App selbst vieles richtig gemacht wurde.

Richtig herausgefunden wo genau das Problem lag habe ich leider nicht. Nachdem der Play-Store in den Settings aktiviert aber immer noch nicht konfiguriert wurde tut die Software anscheinend erst einmal.

A few updates on Open Camping Map

Just in time to the upcomming SOTM 2019 conference I added a few new features to Open Camping Map.

Despite the fact, that the tagging of campgrounds did not improve that much since my first announcement of Open camping Map the new features will hopefully motivate more people to help with the enhancement of campsite tagging.

So what did I add?

Generally the changes are mostly about features not rendered in Standard tile layer or German Style.

At the moment this is mostly about the rendering of tourism=camp_pitch which is rendered in different colors depending on the type of pitch (generic, for tents or permanent residents only).

In addition to this I also added a Plug Symbol for nodes tagged amenity=power_supply.

If you like to have more on the ground icons feel free to post a feature request. I will promise that I will implement it for each additional campsite where it has been added recently by the person requesting the rendering 🙂

Ein paar Gedanken zum Thema Energiewende

Angesichts, der von Greta Thunberg angestoßenen #FridaysForFuture Bewegung bekommen auch Diskussionen über die Energiewende endlich wieder den Stellenwert, den sie angesichts der Lage, in der sich die Welt befindet auch haben sollten.

Insbesondere auf Twitter kommt dann aber immer schnell die Diskussion auf man möge doch auch Kernkraft als Teil der Lösung in Richtung nachhaltigere, decarbonisierte Gesellschaften begreifen.

Ein komplexes Thema, das man sicher nicht in einem Tweet beantworten kann. Ich halte den weiteren Ausbau von Kernenergie, bzw. im Falle Deutschlands den Wiedereinstieg in deren Nutzung, für einen Irrweg und möchte hier kurz in einer Form, wie es auf Twitter nicht möglich wäre erklären warum ich das so sehe.

Nehmen wir hierzu der Einfachheit halber mal an, dass es sowohl die Probleme mit der Endlagerung radioaktiven Mülls als auch die bei heutiger Reaktorsicherheit und heutigem Ausbau etwa alle 25 Jahre stattfindenden größeren Unfälle[1] nicht gäbe.

Des weiteren möchte ich kurz für diejenigen, die den Begriff nicht kennen erklären was Grundlast bedeutet und wie diese in einem konventionellen System der Erzeugung elektrischer Energie genutzt wurde.

Zunächst zur sogenannten Grundlast.

Aufgrund der Tatsache, dass der Bedarf elektrischer Energie tages- und jahreszeitlicher Schwankungen unterliegt und elektrische Energie bisher nicht in großen Mengen speicherbar ist unterteilt man diesen Bedarf in einem klassischen, zentralistischen Energiesystem in die sogenannte Grundlast, die immer benötigt wird und in die sogenannte Spitzenlast, die nur zu bestimmten Tageszeiten benötigt wird.

Früher gab es beispielsweise in Deutschland immer zur Mittagszeit einen erhöhten Bedarf an elektrischer Energie, weil hierzulande viele elektrische Herde und Backöfen verwendet werden. Heute ist das Dank der vielen bereits installierten Photovoltaikanlagen jedoch kaum noch der Fall.

Klassisch wurden Spitzenlasten durch flexibel zuschaltbare Pumpspeicherkraftwerke und Gaskraftwerke ausgeglichen. Die Grundlast lieferten Kohlekraftwerke, Kernkraftwerke und Laufwasserkraftwerke an Flüssen.

Zur Decarbonisierung dieses Systems könnte man nun natürlich ganz klassisch planwirtschaftlich weitere Atomanlagen bauen und versuchen die Gaskraftwerke vollständig durch Pumpspeicherkraftwerke zu ersetzen. Ziel erreicht. Bleibt lediglich kurz anzumerken, dass man für ein solches System nahezu zwangsläufig in die ebenfalls umstrittene Plutoniumwirtschaft einsteigen müsste, denn auch Kernbrennstoffe sind eine endliche Resource.

Während man den Kfz-Verkehr in einem solchen System durch Umstellung auf Elektrofahrzeuge noch halbwegs stemmen könnte gibt es jedoch ein weiteres Problem, dass dieses System nur schlecht lösen kann: Den Bedarf an Wärmeenergie.

Nun zum anderen, vollständig regenerativem Energiesystem, wie es Experten sich für die künftige Energieversorgung in Deutschland vorstellen.

Der bisher noch nicht erwähnte Strom aus Solar- und Windkraftanlagen hat einen prinzipbedingten Nachteil. Während der gefürchteten sogenannten Dunkelflaute, das sind in unseren Breiten windarme Nächte am Jahresbeginn, liefern diese im schlimmsten Fall keine elektrische Energie. Da jedoch auch in diese Zeiten Energie benötigt wird gibt es also nur zwei realistische Szenarios:

Entweder man verzichtet ganz auf diese Energiequellen oder man man sieht Maßnahmen vor diese Energiequellen (temporär) vollständig zu ersetzen.

Vollständig nachhaltig lassen sich erneuerbare Energien durch Generatoren ersetzen, deren Energie (in Zeiten mit viel Wind und Sonneneinstrahlung) aus vorher erzeugten gesammelten Quellen erzeugt wird. Die technisch vielversprechendste Methode für solche Generatoren stellt die Kombination aus Elektrolyse und Gasmotoren dar. Letztere können dezentral betrieben werden, sodass deren Abwärme ebenfalls sinnvollen Zwecken zugeführt werden kann. Logischerweise ergibt sich hier aufgrund physikalischer Eigenschaften ein etwas schlechterer Wirkungsgrad als bei der direkten Nutzung elektrischer Energie, aber auch das oben beschriebene herkömmliche Energiesystem erzeugte jede Menge Abwärme.

Diese Überlegungen führen mich zu meiner Eingangs erwähnten Ablehnung von Kernkraftwerken. Diese sind nämlich prinzipbedingt teuer, zentral und in ihrer Ausgangsleistung schlecht regelbar. Wind und Solarstorm ist hingegen preisgünstig und dezentral.

Deren prinzipbedingten Nachteil, der stark schwankenden Ausgangsleistung muss man zwangsweise mit ebenfalls dezentral aufgestellten Generatoren ausgleichen. Wie das gehen kann habe ich oben beschrieben.

Ein befreundeter Professor aus dem Studiengang Erneuerbare Energien der Hochschule Karlsruhe erklärt mir, dass zur Deckung der Höchstlast in der BRD von 80GW durch Gasmotoren etwa eine Investition von 16 Milliarden Euro notwendig ist[2]. Für den aus seiner und meiner Sicht unnötigen zusätzlichen Netzausbau rechnet man derzeit ca. 80 Milliarden Euro. Zum Vergleich: Das im Bau befindliche Kernkraftwerk Olkiluoto in Finnland wird im besten Fall ca. 9 Milliarden Euro kosten und im Vollastbetrieb ca. 1,6GW an elektrischer Leistung liefern[3].

Damit an dieser Stelle keine Missverständnisse aufkommen: Zum vollständigen Umbau unseres Energiesystems auf dieses System brächte man selbstverständlich nicht nur die Investition in Gasmotoren sondern müsste auch noch die restlichen 50% an elektrischer Energie, die derzeit noch aus Kernenergie und Kohlekraftwerken stammen aus Photovoltaik und Windkraft erzeugen.

Man sollte diese Kraftwerke sogar noch deutlich weiter ausbauen, denn mit dem erzeugten Gas lässt sich dezentral ein Teil der Wärme erzeugen, die immer noch den Großteil des Energiebedarfs hierzulande ausmacht und deren vollständige nachhaltige Erzeugung leider noch immer kein Konzept vollständig löst.

Fazit: Die vollständig nachhaltige Erzeugung aller benötigten elektrischen Energie ist ohne Kernkraftwerke möglich.

Die vollständig nachhaltige Erzeugung aller benötigten Primärenergie ist deutlich schwieriger. In letzterem Fall kann die dezentrale Kombination verschiedener Ansätze helfen. Solche Ansätze reichen von besserer Wärmedämmung an Gebäuden bis zur Nutzung von Erdwärme und Anlagen zur Kraft-Wärme-Kopplung. Die oben erwähnten Gasmotoren können jedoch problemlos Teil einer solchen Infrastruktur zur Erzeugung von Wärme sein.

Ich freue mich über Kommentare und Hinweise auf sachliche Fehler zu diesem Artikel auf Twitter oder auch per Email. Ich selbst war früher ebenfalls kein Kernkraftgegner aber ich sehe wirklich nicht wie uns diese Technologie bei der Aufgabe der Dekarbonisierung unserer Energieerzeugung helfen kann.

[1] Michael Sailer erklärt in Folge 14 des Alternativlos Podcasts, dass hier Theorie und Praxis atomarer Unfälle recht gut zusammen passen.
[2] Laut Aussage eines Ingenieurs von Caterpillar Energy Solutions kostet ein Generatormotor etwa 200 Euro pro Kilowatt elektrisch. Daraus errechnen sich die genannten 16 Milliarden Euro.
[3] Quelle sind die Daten aus der Wikipedia zum derzeit in Bau befindlichen Kraftwerk Olkiluoto

Announcing Open Camping Map

When I started mapping the then newly established backcountry campsites in the Black Forest back in 2017, I discovered, that the current mapping quality of campgrounds in Openstreetmap is actually quite poor. Unfortunately this situation did not improve that much since then.

Being active in OSM for more than 10 years now, I also know that improvements will only happen, when there is an appropriate special interest map which will help motivate people to improve tagging.

So here comes Open Camping Map!

It is provided in the hope, that it will help getting mappers to improve the tagging. There is a bugs section and an edit button besides the actual info about a particular site. The Map will likely be of interest also to camping enthusiasts just looking for a site in a particular area.

Some statistics about the current (bad) state of campsites in Openstreetmap. There are about 120000 camping and caravan sites in our database. About 35000 of them do not even have a name tag. Another 39000 of them do only have a name tag and nothing else. Thus about half of the campsite data in Openstreetmap is of no further value than drawing a (sometimes named) tent on a rendered map.

Wouldn’t it be nice to use Openstreetmap to locate a suitable campsite for your next bicycle or hiking trip or just for your ordinary summer camping holiday?

I do think so, thus lets start and improve the map.

This task is even suitable for armchair mappers as most of the campsites do have a website nowadays. Probably I should also think about adding this to StreetComplete or MapRoulette challenge.

Finally here are some issues I came about while coding this map:

  • Duplicating campsites as node and way ist not a good idea. Please map the area only.
  • Please add at least some contact data to make the data useful for potential customers of a site.
  • caravan only pitches inside a campsite should not to be tagged as caravan_site.camp_site=camp_pitch would be a better option.
  • I invented a tag called permanent_camping=yes,no,only as it is common on many sites in Germany, that people rent a pitch on a seasonal basis and do not move their caravan for years. There are even sites where this is the only option.

So where will I go from here. I intend to make the map multilingual and probably add more improvement on the next Karlsruhe Hack Weekend. I will be happy about further suggestions for improvements or (even better) patches.

The backend is based on PostGIS and Imposm and the associated configuration is also available at GitHub. It is likely suitable for other POI maps. Thus feel free to contact me if you like to build one! The most easy frontend for such a map will likely be uMap.

Happy campsite mapping!

Some thoughts about localization of Openstreetmap based maps

Following this tweet about a request of localized maps on osm.org I would like to share some thoughts on this topic.

My first versions of the localization code used in German style dates back to 2012. Back then I had the exact same problem as Laurence using OSM based maps in regions of the world where Latin script is not the norm and thus I started developing the localization code for German style.

Fortunately I was able to improve this code in December 2015 as part of a research project during my day job.

I also gave some talks about it in 2016 at FOSSGIS and FOSS4G conferences.
Recordings and slides of these talks are available at the l10n wiki.

Map localization seems to be mostly unprecedented in traditional GIS applications as before Openstreetmap there was no such thing as a global dataset of geographical data.

Contrary to my initial thought doing localization „good enough“ is not an easy task and I learned a lot of stuff about writing systems that in fact I not even wanted to know.

What I intend to share here is basically the dos and don’ts of map localization.

Currently my code is implemented mostly as PostgreSQL shared procedures, which was a good idea back in 2012 when rendering almost always involved PostgreSQL/PostGIS at some stage anyway. This will likely change in a vector tile only tool chain used in future. To take this into account in the meantime I also have a proof of concept implementation written in python.

So what is the current state of affairs?

Basically there are two functions which will output either a localized street name or place name using an associative array of tags and a geometry object as input. In the output street names are separated by „-“ while place names are usually two-line strings. Additionally street names are abbreviated whenever possible (if I know how to do this in a particular language). Feel free to send patches if you language does not contain abbreviations yet!

Initialy I used to put the localized name in parenthesis, but this is not a very good idea for various reasons. First of all which one would be the correct name to put in parenthesis? And even more important, what would one do in the case of scripts like arabic or hebrew? So I finaly got rid of the parenthesis altogether.

What else does the code in which way and whats the rationale behind it?

There are various regions of the world with more than one official language. In those regions the generic name tag will usually contain both names which will just make sense if only this tag is rendered like osm carto does.

So what to do in those cases?

Well if the desired target language name is part of the generic name tag just use this one and avoid duplicates at any cost! As an example lets take Bolzano/Bozen in the autonomous province South Tyrol. Official languages there are Italian and German thus the generic name tag will be „Bolzano – Bozen“. Doing some search magic in various name tags we will end up using „Bolzano\nBozen“ in German localization and using „Bolzano – Bozen“ unaltered in English localization because there is no name:en tag.

But what to do if name contains non latin scripts?

The main rationale behind my whole code is that the mapper is always right and that automatic transcription should be only used as a last resort.

This said please do not tag transcriptions as localized names in any case because they will be redundant at best and plain wrong at worst. This is a job that computers should be able to do better. Also do never map automated transcriptions.

Transcriptions might be mapped in cases when they are printed on an official place-name sign. Please use the appropriate tag like name:jp_rm or name:ko-Latn in this case and not something like name:en or name:de.


(Image ©Heinrich Damm Wikimedia Commons CC BY-SA 3.0)

Correct tagging (IMO) should be:
name=ถนนเยาวราช
name:th=ถนนเยาวราช
name:th-Latn=thanon yaoverat
name:en=CHINA TOWN

So a few final words to transcription and the code currently in use. Please keep in mind that transcription is always done as a last resort only in case when there are no suitable name-tags on the object.

Some of the readers may already know the difference between transcription and transliteration. Nevertheless some may not so I will explain it. While transliteration is fully reversible transcription might not always be. So in case of rendered maps transcription is likely what we want to have because we do not care about a reversible algorithm in this case.

First I started with a rather naive approach. I just used the Any-Latin transliteration code from libicu. Unfortunately this was not a very good idea in a couple of cases thus I went for a little bit more sophisticated approach.

So here is how the current code performs transcription:

  1. Call a function to get the country where the object is located at
    (This function is actually based on a database table from nominatim)
  2. If the country in question is one with a country specific transcription algorithm go for this one and use libicu otherwise.

Currently in Japan kakasi is used instead of libicu in order to avoid chinese transcriptions and in Thailand some python code is used because libicu uses a rarely used ISO standard transliteration instead of the more common Royal Thai General System of Transcription (RTGS).

There are still a couple of other issues. The most notable one is likely the fact, that transcription of arabic is far from perfect as vowels are usually not part of names in this case. Furthermore transcription based on pronunciation is difficult as arabic script is used for very different languages.

So where to go from here?

Having localized rendering on osm.org for every requested language is unrealistic using the current technology as any additional language will double the effort of map rendering. Although my current code might even produce some strange results when non-latin output languages are selected.

This said it would be very easy to setup a tile-server with localized rendering in any target language using Latin script. For this purpose you might not even need to use the German Mapnik style as I even maintain a localized version of vanilla OSM Carto style.

Actually I have a Tileserver running this code with English localization at my workplace.

So as for a map with English localization http://www.openstreetmap.us/ or
http://www.openstreetmap.co.uk would be the right place to host such a map.

So why not implementing this on osm.org? I suppose that this should be done as part of the transition to vector tiles whenever this will happen. As the back-end technology of the vector-tiles server is not yet known I can not tell how suitable my code would be for this case. Likely it might need to be rewritten in C++ for this purpose. As I already wrote, I have a proof of concept implementation written in python which can be used to localize osm/pbf files.

A sshd on port 22 hack for Termux on Android

I have always been somewhat skeptic, when it comes to Android. While it is based on the Linux Kernel the Userland is far from the average GNU/Linux system where geeks like me are familiar with for many years now.

I have yet to find some documentation about the way SELinux, the Linux kernel firewall and policy routing are used in Android. The only thing I know about this stuff from digging at the console so far is that they are indeed used.

This is where Termux comes into play. Termux is a console Application which features most of the familiar GNU userland utilities.

There is even an Openssh based sshd for login from a remote machine which is quite handy for console work and file-transfer (e.g. using sshfs).

Unfortunately Android uses a somewhat strange system for isolating applications from each other based on unix user-accounts. Thus, in contrast to our familiar desktop GNU/Linux systems it is not possible for a Termux shell to access data from other applications by default.

This mechanism has two major impacts on our ssh daemon:

  • it does neither make sense to select the desired user on login nor is it possible to switch users for a sshd run by the Termux user anyway
  • ssh (running with the termux userid) will be unable to bind to port 22

For both of those issues it would be nice to have a workaround. I needed to have ssh on port 22 because of a firewall limitation of the eduroam network where my phone is connected to most of the time.

To work around the second issue some kind of sudo mechanism would be needed. For a rooted phone or (even better) a free firmware like LineageOS, which I would recommend tu use, Termux provides a package called tsu which does exactly this.

Back to the sshd on port 22 hack. First I tried to enable file based capabilities (CAP_NET_BIND_SERVICE) on the sshd binary to be able to directly select 22 as the port to bind to. Unfortunately this failed to work likely because of some default SELinux settings I did not understand.

Thus I decided to go for an iptables based approach. Fortunately at least LineageOS does provide an iptables binary.

So here is my runssh script which will run sshd and redirect port 22 to port 8022 (the default Termux ssh port).

#!/data/data/com.termux/files/usr/bin/bash

if [ "$UID" != "0" ]; then
  sshd
  tsu -a -e -c $0
  exit 0
fi

# we are supposed to be root here
# and are able to call iptables
if ! /system/bin/iptables -L PREROUTING -t nat -n |grep -q 8022; then
  echo "setting up redirect form port 22 to 8022"
  /system/bin/iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 8022
fi
Kategorien:

Ein Hoch auf Hüll!

Interessante Hopfensorten für den Selbstanbau


Hopfenanbau ist etwas, das man als Hobbybrauer relativ einfach bewerkstelligen kann. Man benötigt lediglich ein Stück Erde, ein paar Drähte und eine im Idealfall etwa 7m lange Aufspannmöglichkeit. Gut geeignet wäre beispielsweise die Stelle entlang des Dachkanals von Einfamilienhäusern.

Gerade bei „neumodischen Bierstilen“ mit starker Kalthopfung (Hopfenstopfen, dry hopping) kann der benötigte Hopfen ja schon erstaunlich stark ins Geld gehen. So kommt man bei einer Kalthopfung mit 6g/l und einem Preis von 5€/g Hopfen immerhin auf nicht ganz unerhelbliche 30cent pro Liter Bier.

An dieser Stelle kommt der Selbstanbau in Spiel!

Während die klassische Nutzung des eigenen Hopfens zur Bitterung des Bieres schwierig ist, weil man bei selbst angebautem Hopfen den Gehalt an α-Säure nicht kennt, steht dem Einsatz bei der Kalthopfung prinzipiell nichts entgegen.

Woher bekommt man also Hopfensorten, die besonders gut für Kalthopfung geeignet sind. Bevorzugt hätte man in diesem Fall natürlich US-Sorten wie Citra® oder Simcoe® mit fruchtigen Aromen. Dummerweise sind diese beiden Sorten proprietär und die Aufzucht ist dadurch für nicht lizenzierte Betriebe erst einmal prinzipiell verboten.

Pech also für alle diejenigen, die nicht in der Nähe der Yakima Valley AVA leben und dadurch vielleicht das Glück haben einen sprichwörtlich vom Laster gefallenen Steckling zu ergattern.

Was also tun? Dank dem halbstaatlichen Hopfenforschungszentrum Hüll gibt es seit diesem Jahr Alternativen aus deutschen Landen.

Alle Neuzüchtungen aus Hüll sind jetzt über die Firma Eickelmann, die einen Onlineshop für Hopfenflanzen betreibt, zu beziehen. Konkret sind das die Sorten Ariana, Callista, Hallertau Blanc, Hüll Melon, Mandarina Bavaria und Polaris.

Zwar unterliegen auch diese Sorten dem Sortenschutz (siehe Anbau- und Liefervertrag), sind aber wie gesagt für den Hobbybrauer auf dem freien Markt erhältlich.

In der Praxis dürfte wohl auch kaum jemand etwas dagegen haben, wenn man daraus wiederum selbst Stecklinge der eigenen, dort erworbenen Pflanzen für den Eigenbedarf vermehrt.

Funfakt: Im Jahre 2014 wurde mir auf eine Anfrage direkt in Hüll mitgeteilt, dass man ohne Lizenz keine Stecklinge bekommen könne. Schön, dass sich das jetzt geändert hat!

Zum Schluss noch ein paar Worte zu weiteren frei verfügbaren Hopfensorten. Die beiden Hopfensorten Comet und Cascade wurden vom US Department of Agriculture gezüchtet und sind, wie alles was dort mit staatlichen Geldern finanziert wurde, lizenzfrei verfügbar.

Auch die japanische Sorte Sorachi Ace scheint inzwischen lizenzfrei erhältlich zu sein. Leider bietet die Firma Eickelmann aber derzeit keine Pflanzen dieser Sorte an.

Des weiteren sind natürlich auch noch alle bekannten deutschen Sorten erhältlich. Nett für Kalthopfung finde ich davon die Sorte Saphir.

Für Hobbybrauer als Stecklinge verfügbare „flavor Hopfen“

  • Ariana
  • Callista
  • Hallertau Blanc
  • Hüll Melon
  • Mandarina Bavaria
  • Polaris
     

  • Comet
  • Cascade
  • Sorachi Ace (schwer zu bekommen)
     

  • Saphir
  • Alle gängigen deutschen Aroma und Bittersorten

Wer weitere spannende Sorten kennt möge mir diese per Email nennen, damit ich sie zu diesem Blogpost hinzufügen kann.

Kategorien: