Friedrich Volkmann
Davidgasse 78-80/14/10, 1100 Wien, Österreich
www.volki.at / www.steige.info

Please don’t “correct” the objects I have mapped. The error most certainly lies in the validator you are using, not in the data. In any case of doubt, contact me instead of fiddling with the data.

Update Jan 2021: Just out of the hospital after surgery. Looks like I’m going to survive (unless the tumor returns once again), but it has been a horrible time and I’m still not well. I had to think a lot about death recently. It’s obvious that when I leave this world all of the work I have contributed in more than a decade will gradually be destroyed by morons within a few years. That’s how things come and go. Nothing is made for eternity. I am glad that at least I was able to do something useful in my life and people have benefitted from my work.

The rest of this profile is in German, because my mapping activities are mostly limited to Austria.

Schwerpunkte:

• Geländekartierung (Wege, Steige, Gipfel, Höhlen, Täler, Felsen usw.)

• landuse

• historische Objekte

• Landesstraßen

• Luftbildinterpretation

• Dokumentation (Wiki)

• Map Notes

Hauptarbeitsgebiete: Niederösterreich, Nordburgenland, Wien

unterwegs mit Garmin Dakota 20, Editor: Merkaartor 0.17

Ich mache Luftbildmapping, dabei können mir Fehler unterlaufen, z.B. falsche Tracktypes. Wenn ihr so etwas durch aktuelle Ortskenntnis besser wisst, korrigiert es ruhig.

Ich bin aber auch sehr viel im Gelände unterwegs. Ich habe mich durch Felsen, Unterholz und Gestrüpp geplagt um die Positionen von Höhlen, Gipfeln usw. mit GPS einzumessen. Dabei habe ich mir schon einige Augenverletzungen zugezogen, und ich habe zigtausend km mit dem Auto verfahren. Bitte meine Daten daher mit Respekt zu behandeln. Wenn ihr glaubt, sie gröber ändern zu müssen, kontaktiert mich vorher!

Seid euch bewusst, dass:

• die Angaben (z.B. Namen) in kommerziellen Karten manchmal falsch sind

• die Orthofotos von Bing oft stark lageverschoben sind

• auch die Orthofotos von geoimage.at nicht immer lagerichtig sind

• besonders bei Felswänden und Steilhängen massive Verzerrungen und Lagefehler in den Orthofotos sind

• das Höhenmodell von SRTM Fehler bis 200m aufweist und manche Berge ganz durch den Raster fallen

• die Orthofotos nicht immer aktuell sind

• die Berge höher sein können als in der Amap, weil sich die Höhenangaben dort oft auf den Vermessungspunkt beziehen und nicht auf den Gipfel

Die Namen habe ich aus verschiedenen Quellen (Tafeln vor Ort, aktuelle Karten, franzisco-josephinische Landesaufnahme, Bücher…). Wenn ihr abweichende Informationen habt (z.B. unter Anwohnern übliche Namen), lasst es mich wissen.

Ähnliches gilt für Straßennamen. Mit dem plan.at-Import wurde OSM mit Ortsnamen als Straßennamen zugemüllt. Das Ausmisten dauerte Jahre. Seit basemap.at in den Editoren als Hintergrund zur Verfügung steht, werden die selben falschen Straßennamen schon wieder importiert von Leuten, die sie abschreiben ohne nachzudenken. Besonders ärgerlich ist das, wenn meine vor Ort erfassten Straßennamen dadurch überschrieben werden.

Weitere Anliegen an euch:

1. Seid vorsichtig mit Validatoren wie OSMI. Sie meckern oft Dinge an, die eh richtig sind. Beispielsweise “touching inner rings”. Bitte nicht an den Multipolygonen herumdoktorn, um diesen vermeintlichen Fehler zu korrigieren. Ihr könnt damit nur was hinmachen. Ich erfasse touching inner rings bewusst, und jedes Mal sind sie bald danach durch die OSMI-Gefolgschaft verunstaltet.

2. Versucht bitte zwischen Landuses keine Streifen frei zu lassen. Es gibt kein Niemandsland. Auch eine Straße zwischen Wald und Wiese ist kein Niemandsland, sondern sie bildet die Grenze.

3. Erfasst bitte sprechende Changeset-Kommentare, damit man nachvollziehen kann, was ihr gemacht habt und warum. Wo gehobelt wird, fallen Späne. Wenn etwas schiefgeht, ist es für die Reparatur wichtig zu wissen, was mit dem Changeset beabsichtigt war.

Gedanken zum Rendering

Als ich mit OSM anfing, war mir schnell klar, dass an den Renderern noch viel zu verbessern ist, bzw. dass man sie von Grund auf neu konzipieren müsste, um eine ordentliche Generalisierung zu ermöglichen. Ich wollte daher einen eigenen Renderer schreiben, habe das aber noch nicht gemacht, weil ich mich auf keine Ziele festlegen konnte.

Es gibt nämlich verschiedene Anwendungen für Karten, und abhängig davon muss der Renderer konzipiert werden:

A) Slippy map: Eine Karte im Web, die man verschieben kann und wo man rein und raus zoomen kann.

1. Hier spielt es keine Rolle, ob Beschriftungen aus der Karte hinausragen, da man die Karte verschieben kann. Die Beschriftungen sollten aber so platziert werden, dass sie möglichst wenig anderes überdecken ohne dass die Zuordnung unklar wird (eine attraktive Optimierungsaufgabe).

2. Es können beliebig viele Details angezeigt werden, zwar nicht in jeder Zoomstufe, aber für jeden Mistkübel und Kanaldeckel ist ab einer gewissen Zoomstufe genug Platz. Das hängt vom Gebiet ab. In der Wüste wird man Tracks auch in einer niedrigen Zoomstufe anzeigen, in der Großstatt wird der Renderer auf einer mittleren Zoomstufe vielleicht sogar Hauptstraßen weglassen um die Übersichtlichkeit zu wahren. Diese Logik auszuprogrammieren ist im Grunde einfach: Detaillierungsgrad proportional zur Datendichte.

3. Die Beschriftungen dürfen ruhig etwas größer sein, v.a. von den wichtigeren Objekten, da die von der Beschriftung verdeckten (oder dafür ganz weggelassenen) Details in höheren Zoomlevels sowieso erkennbar werden. Es geht nicht darum, gleich alles in den kleinen Maßstäben zu sehen, sondern einen Überblick zu gewinnen, welchen Kartenausschnitt man sieht und wo man weiter hineinzoomen möchte. Ein Beispiel, wie man’s nicht machen soll, ist Mapnik, wo die Schriften unlesbar und die Städtenamen kaum auffindbar sind.

4. Es sollten die Möglichkeiten des www genutzt werden: Events auswerten, Verlinken usw. Wenn man ein Objekt anklickt, kann ein Fenster mit der Beschreibung (description=*), der Adresse usw. aufgehen, mit dem Link auf die Website… Weiters kann es in einem Konfigurationsmenü eine Auswahl geben, was in der Karte alles angezeigt werden soll… wie groß die Signaturen und Beschriftungen sein sollen… und diese Einstellungen können in einem clientseitigen Cookie oder (nach Anmeldung) am Server gespeichert werden.

5. Die Seiten können teilweise clientseitig gerendert werden. Signaturen können 1x heruntergeladen und dann beliebig oft angezeigt werden. Das spart Rechenleistung am Server und Bandbreite.

6. Für Smartphones gelten die bekannten Anforderungen. Sie sind für Apps und Webseiten gleich.

B) fixe Kartenausschnitte: Entweder zum Ausdrucken zum Mitnehmen, oder für statische Einbindung in Bücher, Zeitungen, Webseiten, Office-Dokumente etc.

1. Die Beschriftungen dürfen nicht über den Rand hinausgehen, ansonsten gilt das gleiche wie unter A1.

2. Der Renderer sollte möglichst viele Optionen bieten, aber im Ggs. zu A sind Kartenkonfiguration und -nutzung mindestens zeitlich voneinander getrennt.

C) Karten für GPS-Geräte:

1. Hier ist die Konfigurierbarkeit bei der Erstellung besonders wichtig, da die Anforderungen individuell sehr verschieden sind.

2. Ein lästiges Problem ist, dass die Hersteller (v.a. Garmin) keine Spezifikationen herausgeben, weil sie ihre eigenen Karten anbringen wollen.

3. Für die Anzeige gelten ähnliche Anforderungen wie bei Smartphones, wobei die Einschränkungen durch HW und Firmware aber größer sind (Anzahl Farben, Zoomlevels usw.).