Bei einer kleinen Radtour entlang der Autobahn-Baustellen bin ich auf ein paar ‘interessante’ Schilder der Autobahnmeisterei gestoßen.

Die Lotsenpunkte sollen den Baustellenfahrzeugen (und eventuell später auch Einsatzkräften?!) helfen, einfacher an den Zielort zu kommen. Als hätte Andi nicht schon genug Geld verschwendet, scheint jetzt auch noch Geld in W3W zu fließen :-(

Ich möchste hier eine kleine Zusammenfassung der diesjährigen FOSSGIS-Konferenz wiedergeben um zum einen zum Ausdruck zu bringen, dass die Konferenz wirklich super war und (wie jedes Jahr) sehr viel Spaß gemacht hat und zum anderen um etwas Werbung zu machen damit nächstes Jahr hoffentlich noch mehr Leute aus der OSM-Community vorbeischauen und mitmachen.

Die Konferenz fand dieses Jahr in Salzburg statt und ging direkt der jährlich an der Salzburger Uni stattfindenden AGIT voraus. Dadurch ergab es sich, dass die FOSSGIS von Montag bis Mittwoch und nicht wie sonst von Mittwoch bis Freitag stattfand, und somit die Ausrichtung eines speziellen OSM-Sonntags ermöglicht wurde. Der OSM-Sonntag war ein wirklich tolles Extra und hat mir sehr gut gefallen! Da vor allem OpenStreetMapper anwesend waren, war das ganze noch etwas familiärer und man konnte sich noch besser über aktuelle Themen und Projekte unterhalten und informieren. Ich hoffe, dass sich auch künftig wieder eine Möglichkeit findet, solch einen speziellen OSM-Tag zu veranstalten. Wichtig ist, das er am Wochenende liegt, da dann einfach mehr Leute Zeit haben und sich nicht extra Urlaub nehmen müssen.

Michael hat im Blog eine sehr nette und vor allem treffende Zusammenfassung geschrieben. Ich kann auch die Vorträge dazu eigentlich alle empfehlen.

Zum offiziellen FOSSGIS-Programm gab es auch eine Vielzahl interessanter Vorträge und Gespräche. Ich habe selbst nicht alle angeschaut, möchte aber dennoch ein paar Empfehlungen abgeben.

Dazu gehört der Vortrag Jenseits von Mercator von Christoph und insbesondere auch der tollen Demo der Quincunx-Projektion. Die Vorträge Flächen und Kanten von Roland, die Bachelorarbeit von Nathanael Lang und Jakob Miksch’ Masterarbeit widmen sich alle vornehmlich dem Fußgängerrouting und Routing über Flächen. Etwas das ich mir schon lange wünsche, aber leider bisher noch nirgends wirklich gut umgesetzt wurde. Aber vielleicht wird das ja demnächst etwas mit z.B. der Arbeit von Jakob. Zudem sollte man sich Frederiks Vortrag zu automatischen Edits und Importen ansehen: Damit man mal sieht, was alles für Scheiss importiert wird und warum die DWG (zu) viel Arbeit hat!! :-)

Am Dienstag gab es dann von Manuel Roth und Kollegen einen Vortrag zu Vector Tiles um deren Arbeit es wohl auch etwas Ärger mit Mapbox gibt. Der Vortrag ist auf jeden Fall sehenswert. Ebenso empfiehlt sich Serhan Şens Vortrag über den Leitstellensimulator. Er zeigt eindrucksvoll den hohen Aufwand für dessen Betrieb, zeigt aber auch, wie mit solchen Projekten neue Mapper gewonnen werden.

Am Mittwoch fand ich besonders den Vortrag OSM schön gemacht interessant. Der Vortrag war gut aufgezogen und die von Mark Padgham neu erstellten R-Pakete sahen sehr vielversprechend aus. Vielleicht doch endlich mal ein Grund die eigenen R-Kenntnisse zu verbessern! ;-)

Es gab sicherlich noch viele weitere interessante Vorträge die ich hier nicht erwähnt habe und ich habe bisher auch selbst noch nicht alle Vorträge angeschaut. Man unterhält sich dann eben doch öfter auch mal mit anderen OpenStreetMappern oder hilft dem Videoteam bei Schnitt und Kontrolle. Ich bin mir aber sicher das ich auch die restlichen Vorträge noch ansehen werde. Guckt selber einfach mal die Liste aller Vorträge durch.

Viel Spaß beim Anschauen der Vorträge und ich hoffe es bekommen dann noch mehr Leute Lust, nächstes Jahr eben doch auch persönlich aufzutauchen und sei es nur an einem “OSM-Sonntag”.

This article is supposed to give a brief introduction about water in OpenStreetMap. It will show you typical errors made by mappers and how they can be fixed with the help of MapRoulette.

The Water Network

Mapping water in OSM can be divided into two categories. On the one hand there are area types of water like ponds, lakes, reservoirs and even whole river areas (waterway=riverbank) and as a special case the sea (natural=costline). On the other hand there are simple ways, the waterways: These are rivers, streams, canals, ditches and drains.

The water network is thus built by the waterways. This also means that a broad river mapped as riverbank additionally contains a waterway=river in between. Thereby the direction of the way also denotes the direction of the water flow. If you follow a river or stream, you should at some point reach a big lake or the see. How to identify the direction of a way is explained on this wiki page.

Unfortunately the water network in OSM is broken at many places. As a result, some rivers appear to flow uphill or spring from the sea.

SRTM and MapRoulette

SRTM provides height data for mostly the whole planet for free. It makes it possible to determine for any waterway in OSM if it flows downhill or uphill. Though the data is unprecise, many waterways are quite long which makes it quite reliable to identify the direction of flow for many rivers and streams. However, one can’t advise to start an automatic mass edit based on SRTM. Having said that, there’s a neat project called MapRoulette, helping to solve such problems by letting the OSM community decide on small tasks. Thus there is a new challenge in MapRoulette to check on the waterway’s direction. Each task is one waterway that supposedly flows uphill and its flow direction has to be turned.

The difficulty of the tasks will grow over time. If the difference of height is some hundred of meters it’s simple in most cases. For smaller differences, e.g. 10 meters, it might well be a error in SRTM. However, the challenge will start with the easy tasks. And still there will be extra help: Each task’s instruction contains the height difference from the start to the end of the way as an additional help.

False Positives

It’s not always as easy as one might think. There are some cases that need special attention that are listed below. * A canal might be tagged as a river or stream. In contrast to rivers or streams a canal may “flow” uphill. Particularly: What’s the direction of a canal anyway? * Not every fork is a confluence. There are cases where a river splits up into two ways. * There are rivers and streams that dry out or drain away. Thus they “disappear” from the map. But you may not conclude that this is a spring.

Errors and Error Detection

The following paragraph will show some scenes with errors in the water network. It should give you an impression, how to determine (and repair) common mistakes.

All screenshots showing imagery are proprietary and based on GEOIMAGE-AUSTRIA® (c.f. wiki)

Mountains

In mountainous regions you typically get a large difference in height. An example of this can be seen in the following JOSM screenshots: The complete stream, the start and the end of the stream As one can clearly see, the stream originates high up in the mountains and finally leads in a larger river in the valley. Downloading the data in the surrounding area one can additionaly check, if the stream and river are connected or not. The right image below shows the result after correcting the direction of the way. ## Forks If you check a waterway, it is also wise to investigate the complete way for forks. It happens quite often that more than one stream flows uphill as it was tagged by the same author. This might look like this: ## Water Mouth Quite easy cases are rivers and streams that end in the sea. This can be detected, as the waterway is connected to the coastline. Thus, the way’s direction has to lead to the sea. ## Defective Parts of the Way In some cases only parts of a waterway are directed in incorrect. In these cases one part has to be wrong, but one also has to be cautious to correctly determine which part is wrong. # Additional Notes The network of waterways should be fully linked. Thus, it is advisable to also verify that ever way’s end is connected to the next waterway. Especially ways should not end at riverbanks but at a river or stream.

Further typical errors or missing notes are welcome. I’d add them here

Any changeset’s source tag should at least contain SRTM as a source.

Im Folgenden soll ein kleiner Überblick über Wasser in OpenStreetMap gegeben werden, die typischen Fehler erklärt werden und mit MapRoulette ein Weg aufgezeigt werden, diese Fehler einfach und schnell zu beseitigen. # Das Wassernetzwerk in OpenStreetMap Das Mapping von Wasser in OSM unterteilt sich in 2 große Kategorien. Zum einen gibt es Wasserflächen die gemappt werden. Dies sind z.B. Weiher, Seen, Wasserreservoirs aber auch eine genaue flächenmäßige Erfassung von Flüssen (waterway=riverbank) und als Spezialfall das Meer. Zum anderen sind dies Wasserwege. Das sind die Flüsse (river), Bäche (stream), Kanäle (canal), Bewässerungsgräben (ditch) und Abwasserkanäle (drain).

Das eigentliche Wassernetzwerk wird dabei ausschließlich durch die Wasserwege aufgespannt, so dass ein breiter Fluss der als riverbank gemappt ist stets zusätzlich den eigentlichen Wasserweg (waterway=river) enthält. Die Richtung des Weges gibt dabei gleichzeitig die Flussrichtung des Wassers an. Verfolgt man also einen Bach oder Fluss immer weiter, sollte man irgendwann in einem großen See oder im Meer enden. Wie man die Richtung des Flusses (des Weges) erkennen kann, erklärt dieser Wikiartikel.

Leider ist das Wassernetzwerk an vielen Stellen in OpenStreetMap unvollständig bzw. kaputt, so dass Flüsse schon mal bergauf fließen oder im Meer entstehen statt dort zu enden. # SRTM und MapRoulette Mit SRTM gibt es eine nahezu weltweite Abdeckung mit frei verfügbaren Höhendaten. Dadurch ist es einfach möglich, für Wasserwege in OSM zu prüfen, ob diese bergauf oder bergab fließen. Zwar sind die Höhendaten an vielen Stellen relativ ungenau, durch die typischerweise sehr langen Wasserwege kann man aber für viele Flüsse und Bäche recht zuverlässig bestimmen, ob diese richtig gemappt sind. Dennoch, eine automatische Korrektur auf Basis dieser Daten ist nicht zu empfehlen. Mit MapRoulette gibt es aber ein nettes Projekt, dieses Problem zu lösen: Man teil das Problem (Challenge) in kleine Aufgaben (Tasks) und lässt diese von der OSM-Community lösen. Es gibt daher eine neue Challenge, Wasserwege zu korrigieren und somit das Wassernetz zu verbessern. Jeder Task ist dabei ein Wasserweg der vermeintlich bergaufwärts läuft und umgedreht werden muss.

Der Schwierigkeitslevel wird dabei mit der Zeit steigen. Bei einer Höhendifferenz von mehreren Hundert Metern ist der Fall meist leicht, bei einer Höhendifferenz von 10 Metern kann es sich aber auch schnell um Fehler in den SRTM-Daten handeln. Beginnen wird die Challenge aber anfangs mit den eher eindeutigen Fällen. Dennoch ist als zusätzliche Hilfe für jeden Task die Höhendifferenz von Weganfang zu Wegende angegeben. # Falsepositiv Aber nicht immer ist der Fall so einfach wie man anfangs denkt. Daher gibt es hier eine kurze Liste von Dingen, die man beachten sollte bzw. warum es eben doch vorkommen kann, dass der Wasserweg bereits korrekt ist. * Durch eine falsche Klassifikation kann ein Kanal als Bach bzw. Fluss getaggt worden sein. Kanäle können aber im Gegensatz zu Bächen und Flüssen durchaus bergauf “fließen” und besitzen insbesondere meist keine Richtung im eigentlichen Sinn. * Nicht immer ist eine Kreuzungsstelle von Wasserwegen ein Zusammenfluss. Es gibt durchaus Bäche und Flüsse, die sich teilen und in zwei unterschiedliche Richtungen weiterfließen. * Es gibt Bäche und Flüsse die austrocknen/versickern oder einfach nicht mehr sichtbar sind und somit von der Karte “verschwinden”. Man darf daher nicht daraus schließen, dass es sich um eine Quelle handelt. # Fehler und deren Erkennung Im Folgenden werden einige typische Szenarien gezeigt, in denen das Wassernetz einen Fehler enthält. Es soll grob vermitteln, wie man diese Fehler identifizieren (und reparieren) kann.

Die Screenshots im Folgenden zeigen zum Teil Luftbilder. Diese unterliegen dem Markenschutz von GEOIMAGE-AUSTRIA® (siehe hier ). ## Gebirge Vor allem bei großen Höhenunterschieden hat man es typischerweise mit Gebirge zu tun. Die folgenden drei Bilder zeigen einen solchen Fall in JOSM mit den jeweiligen Ausschnitten von Bachanfang und -ende. Wie man recht klar erkennt, entspringt der Bach weit oben am Berg und mündet im Tal in einen größeren Fluss. Dies erkennt man noch besser, wenn man sich auch noch die Daten aus der Umgebung herunterlädt. So kann man auch gleich noch prüfen, ob der Bach auch mit dem Fluss verbunden ist. Im rechten Bild ist dann das Ergebnis, nach dem Ändern der Flussrichtung sichtbar und man kann sein Ergebnis hochladen. ## Verzweigungen Bei der Korrektur von einzelnen Wasserwegen solle man zudem prüfen, ob der Bach unter Umständen Verzweigungen aufweist. Dies sind oft Stellen, wo gleich mehrere Wasserwege die falsche Richtung aufweisen, da sie vom selben Autor gemappt wurden. ## Meeresmündung Sehr einfach erkennbar sind Flüsse und Bäche, die im Meer enden. Der Wasserweg schließt dabei an die Küstenlinie (natural=coastline) an, die Flußrichtung muss entsprechend im Meer enden. ## Falsche Teilstücke In einigen Fällen passiert es auch, dass ein angeschlossener Wasserweg bzw. ein Teilstück des Wasserwegs eine falsche Richtung aufweist. Hier ist etwas Vorsicht geboten, da man noch prüfen muss, welcher Teil des Wasserweges den Fehler aufweist. # Weitere Hinweise Da das Wassernetz vollständig vernetzt sein sollte, ist es ratsam, bei Korrekturen zu prüfen, ob der Wasserweg korrekt an den nächsten Wasserweg angeschlossen wurde. So sollte der Wasserweg insbesondere nicht an der riverbank sondern am Fluss selbst enden.

Beim Hochladen der Korrekturen sollte im source-Tag des Changesets unter anderem SRTM als Quelle genannt werden.

Viel Spaß