Wir kommen zum letzten Vortrag in diesem Hörsaal vor der Abschlussveranstaltung, nach der es natürlich dann noch mit OpenStreetMap-Special weitergeht. Aber auch dieser Vortrag behandelt jetzt OpenStreetMap,

auch ein Jahrzehntelang schon dabei seiner Mapper. Und es geht um ein Thema, das wurde schon mal in einem OSM-Radio-Podcast erschöpfend behandelt. Wer da noch mal nachschauen will und sich da noch mal informieren will,

wie der Stand vor vier, fünf Jahren war, der kann da noch mal nachhören. Er erzählt uns jetzt aber über die aktuelle Situation in seiner Open Realm-Karte. Und das ist Alexander Mattheisen. Und er erzählt uns jetzt, wie er seine Karten eben produziert.

Viel Spaß. Herzlich willkommen zu meinem Vortrag über die Produktion generalisierter Eisenbahnkarten. Um dann auch kurz daran anzuschließen, es geht jetzt nicht um die Open Realm-Map. Das ist mein Hobbyprojekt.

Beruflich befasse ich mich aber auch mit Eisenbahnkarten. Und da werde ich heute ein Projekt vorstellen. Genau das Projekt, was ich heute vorstellen werde, ist in einer Arbeitsgemeinschaft von Geops mit der Grafikagentur EVOC in Zürich und dem Auftraggeber der SBB entstanden.

Kurz zum Inhalt des Vortrags. Ich werde zunächst mich und die Firma Geops vorstellen. Und einige unserer Projekte, um dann eine Überleitung zu haben

zur Motivation für dieses Projekt und den Herausforderungen, die sich dabei ergeben haben. Dann werde ich näher eingehen auf die Aggregation und Generalisierung der Streckennetzdaten. Einen Workflow vorstellen, mit dem die Karten dann produziert werden.

Wie wir Fachinformationen auf dieses Netz dann referenzieren können und schließlich noch einen kleinen Ausblick geben. Genau, zunächst zu mir. Mein Name ist Alexander Mattheisen. Ich bin jetzt inzwischen seit zweieinhalb Jahren als Entwickler bei Geops tätig. Schwerpunktmäßig befasse ich mich dort mit der Backend-Entwicklung,

insbesondere der Verarbeitung von Open-Street-Map-Daten oder Fahrplandaten. Das hat auch ein bisschen mit meinem Hintergrund zu tun. Ich bin jetzt inzwischen seit mehr als zehn Jahren im Open-Street-Map-Projekt aktiv und dadurch so ein bisschen in der Rolle des USM-Experten in der Firma.

Insbesondere auch was Eisenbahn-Daten in USM betrifft. Denn wie in der Einleitung schon angesprochen, bin ich auch der Betreiber der Open-Railway-Map. Und denen, denen das jetzt nicht sagt, das ist eine Karte der Eisenbahn-Infrastruktur auf USM-Basis, die ich mehr oder weniger als Hobbyprojekt pflege.

Genau, meinen Arbeitgeber, die Firma Geops, gibt es seit 2002. Wir haben Niederlassungen in Freiburg in Deutschland und in Frenkendorf in der Schweiz. Aktuell sind wir ein Team von 15 Mitarbeitern mit verschiedenen Hintergründen.

Darunter Informatiker, Geografen und ÖV-Spezialisten. Unsere Arbeit reicht von der Geodaten-Analyse über die Visualisierung und die Erstellung von Web-Applikationen bis hin zu Fahrgast-Informationssystemen mit Echtzeitdaten.

Dabei setzen wir auch sehr stark auf Open-Source-Technologien. Neben der Nutzung ist für uns dabei auch wichtig, Open-Source selbst zu fördern, etwa durch eigene Veröffentlichungen auf GitHub oder durch das Sponsoring von Konferenzen.

Unser Fokus liegt dabei auf Anwendungen im Bereich des öffentlichen Verkehrs. Eine Anwendung, die vielleicht der eine oder andere schon mal gesehen hat, ist Travic. Travic ist ein ÖV-Tracker, wo anhand von statischen Fahrplandaten und vorhandenen Echtzeitdaten die aktuellen Positionen und exakten Fahrtverläufe von Fahrzeugen visualisiert werden.

Da sind inzwischen über 700 Verkehrsunternehmen weltweit integriert. Mit richtigen Echtzeitdaten arbeitet die App S-Bahn München live, die wir für die Deutsche Bahn erstellt haben. Da werden dann anhand der aktuellen GPS-Positionen der S-Bahn

die Standorte der Züge auf einem schematischen Liniennetzplan oder einer Karte angezeigten Abfahrtsprognosen erstellt. Ein weiteres Beispiel für unser Projekt ist eine App für das Swiss Travel System.

Das richtet sich an Touristen und visualisiert touristische Highlights auf der Karte und die Gültigkeit von touristischen Angeboten auf den verschiedenen Strecken. Die Anforderungen, die bei all diesen Projekten an die eingesetzten Karten sich stellen,

sind hochwertige Karten mit einer übersichtlichen Darstellung des öffentlichen Verkehrs bzw. des Eisenbahnnetzes. Die hohe Darstellungsqualität wird dabei durch eine manuelle Generalisierung und Optimierung der Karte erreicht.

Wichtig ist aber auch, dass die Karten nicht nur zu Darstellungszwecken genutzt werden können, sondern dass auch weitere Informationen darauf abgebildet werden können. Auch wichtig ist, dass die Karten länderübergreifend sind. In der Schweiz gibt es mit Traffi Marsch bereits solche Karten.

Unter dem Namen Traffi Marsch veröffentlicht die Schweizerische Bundesbahn SBB Karten des öffentlichen Verkehrs in der Schweiz mit den Streckennetzen der Züge, sowohl als Print- als auch als Webkarten. Geops übernimmt dabei die Entwicklung der interaktiven Karten im Webkartenportal.

Die Karten in der Schweiz basieren auf einem Datensatz des Schweizer Bundesamtes für Verkehr. Das hat dann natürlich zur Folge, wenn man aus der Karte rauszoomt und stellt man fest, wird halt nur die Schweiz abgebildet. Es gibt aber halt viele Fälle, in denen es nützlich wäre,

wenn man auch eine Abdeckung außerhalb der Schweiz hätte. Es gibt halt im Personenverkehr grenzüberschreitende Fernverkehrszüge von der Schweiz bis nach Hamburg oder Mailand. Oder im Güterverkehr auch grenzüberschreitende Containerzüge von der Nordsee bis ans Mittelmeer.

Und Auslöser für das hier vorgestellte Projekt ist eben gewesen, die Ausdehnung dieser Traffi-Marschkarte auf einen großen Teil Europas auszudehnen. Herausforderungen dabei, wenn man das Kartenmaterial auf andere Länder ausdehnen will, ist zuerst mal die Frage, welches Datenmaterial als Grundlage verwendet werden kann.

In Deutschland zum Beispiel bietet die Deutsche Bahn in ihrem Open-Data-Portal immerhin einen entsprechenden Datensatz an. Der hat aber zum Beispiel den Nachteil, dass private Infrastrukturbetreiber da nicht enthalten sind. Und unser Anspruch ist schon wirklich das gesamte Bahnnetz abzubilden,

weshalb dieser Datensatz dann nicht in Frage kam. Und ein Problem ist eben, dass in vielen Ländern gar keine entsprechenden Datensätze verfügbar sind. Von daher war schnell klar, dass Open-Street-Map-Daten hier die einzige brauchbare Quelle sind, die wir für solche Karten verwenden können.

Durch die Entscheidung, dass wir Open-Street-Map-Daten verwenden, hat sich dann eine weitere Frage ergeben, nämlich wie kann man aus diesen gleisgenauen Daten automatisiert streckengenaue Daten an der Knotenkantentopologie erzeugen. Wie kommt man praktisch von den rohen OSM-Daten, wie man sie da oben sieht,

zu so einer vereinfachten Streckentopologie wie hier unten. OSM hat dann das Problem, man hat eben jedes Gleis einzeln erfasst. Die Gleise sind auch aufgesplittet an Brücken oder wo sich irgendwelche Texte ändern.

Man hat eben nicht so eine Struktur, dass man praktisch die Stationen als Knoten hat und jeweils Kanten, die die Station verbinden, die die Strecken darstellen. Ein weiterer wichtiger Aspekt ist, wie man dabei eine hohe kartografische Qualität erreicht. Die Karten in der Schweiz, die wurden bisher von unserer Partnerfirma

dann noch in einem Grafikprogramm nachbearbeitet, insbesondere um zum Beispiel die Platzierung der Labels zu steuern. Für eine Karte von ganz Europa ist der Ansatz aber mit einem hohen manuellen Aufwand verbunden und nicht mehr so sinnvoll. Dennoch möchte man aber eine höhere Darstellungsqualität erreichen

als bei einem automatisierten regelbasierten Kartenrendering, wie es bei Webkarten heute üblich ist. Dazu haben wir einen Workflow entwickelt, der datengetriebenes Styling nutzt

und die verschiedenen Prozesse automatisiert, um da den manuellen Aufwand der Kartenproduktion deutlich zu vereinfachen. Da werde ich später noch darauf näher eingehen. Zunächst möchte ich auf die initiale Erstellung des generalisierten Datensatzes eingehen.

Die gesamte Verarbeitung findet in einer Postgres- bzw. Postgres-Datenbank statt, unter Verwendung umfangreicher Postgres-Funktionen. Im ersten Schritt werden dazu die Open-Suite-Map-Daten in die Datenbank importiert und dann gefiltert, sodass man im ersten Schritt nur noch die wirklich relevanten Daten erhält,

nämlich die Streckengleise und die Betriebspunkte. Das heißt, Nebengleise kann man schon mal anhand der Text rausfiltern und alles, was eben nicht relevant ist. Dann im nächsten Schritt passiert dann die eigentliche Aggregierung der Gleisezustreckengeometrien

und die Herstellung der Knotenkantenstruktur. Dabei kommt unter anderem Routing zum Einsatz. Das heißt, wir erzeugen ersten Schritt eine Topologie aus den Daten und mit PG-Routing werden dann die kürzesten Wege zwischen den Stationen berechnet.

Das heißt, man erhält halt so, auch wenn man zwischen Stationen mehr gleisige Strecken hat, dann im Grunde immer einen kürzesten Pfad und eine einzige Geometrie zwischen jeweils zwei Stationen.

Verschiedene Heuristiken sorgen dann dafür, dass man nur so viele kürzeste Pfade berechnen muss wie unbedingt notwendig. Das heißt, man routet nicht zwischen allen Stationen im gesamten Netzwerk, sondern nur zu Stationen, die über Routenrelationen praktisch mit den Stationen irgendwie in einer Beziehung stehen

oder die in einem gewissen Radius um eine Station sind. Genau, die aggregierten Daten, die werden dann in drei Generalisierungsstufen exportiert. Das heißt, man hat drei verschiedene Graphen, die topologisch aber alle identisch sind.

Das werden automatisiert dann nur die Geometrien schon mal vereinfacht. Dass wir dann die Daten in drei verschiedenen Generalisierungsstufen haben, erlaubt es dann, dass wir bei der späteren Karte dann je nach Zoom-Stufe unterschiedlich stark generalisierte Karten einsetzen können.

Das kann man hier auf der Abbildung zum Beispiel gut sehen. Man hat hier eine höhere Zoom-Stufe. Da kann man zum Beispiel sehen, diese Schnellfahrstrecke aus Richtung Süden, die nach Mannheim führt. Sie ist hier noch parallel erfasst, während es hier in einer niedrigeren Zoom-Stufe dann so zusammengelegt wurde,

dass die Strecken dann übereinander liegen. Wie angesprochen, die Topologie zwischen den Generalisierungsstufen ist aber stets identisch. Diese ganze Generalisierung, das erfolgt rein durch die Steuerung der Sichtbarkeiten und die Bearbeitung der Geometrien.

Auch noch ein schönes Beispiel ist jetzt hier Paris. Da kann man sehen, wie dann je nach Zoom-Stufe die Stationen generalisiert wurden. In der niedrigen Zoom-Stufe ist Paris halt lediglich ein einziger Stationspunkt.

In den höheren Zoom-Stufen sind dann die einzelnen Bahnhöfe aufgeteilt. Das ist jetzt der gesamte Workflow zur Kartenproduktion von den generalisierten Daten ausgehend bis schließlich zur fertigen Karte.

Die Datenbank ist eine klassische PostGIS-Datenbank, die diese im Initialerzeugen generalisierten Streckendaten enthält. Dazu gibt es dann einen von uns entwickelten Editor, mit dem diese Daten dann bearbeitet werden können.

Im Wesentlichen ist das eben diese händische Optimierung der Geometrien und die Anpassung von Attributen, die für Styling relevant sind. Wenn die Daten dann fertig bearbeitet sind, werden die mit OGA2OGA und TPKNU ins MB-Teils-Format konvertiert.

Über eine CI wird das Ganze dann auch automatisch auf einem Teilserver deployed. Diesen Export kann der User dann über einen Button im Editor selbst anstoßen. Für eine Karte braucht man natürlich auch noch einen Style. Das Styling findet in Maputnik statt. Das ist ein grafischer Style-Editor, sodass

der User ein direktes Feedback dazu bekommt, wie die spätere Karte dann aussieht. In dem Style werden dann eben verschiedene Attribute ausgewertet, die im Editor in Daten erfasst wurden.

Und daraus ergibt sich dann so ein iterativer Prozess, dass man dann im Style verschiedene Attribute auswertet und dann sieht, die Darstellung passt noch nicht. Geht wieder in den Editor, passt die Daten an und das ist dann eben so eine Feedback-Schleife, die sich dabei ergibt.

Wenn dann der Style fertig bearbeitet ist, wird er dann aus Maputnik exportiert. Und über einen Web-Interface kann man ihn dann auch per Dragontrop reinziehen und das Ganze wird dann eben auch auf einen Teilserver deployed. Genau, als Teilserver wird dann Teilserver GL eingesetzt, der dann schließlich entweder Raster oder Vector-Kacheln ausliefern kann.

Auf einzelne Komponenten gehe ich jetzt noch mal näher ein. Zunächst der Editor. Wie gesagt, da findet vor allem die Attributbearbeitung statt. Z.B. Sichtbarkeiten, Label-Positionen und Labelnamen, dass man eben, wie z.B. im Beispiel von Paris, je nach Generalisierungsstufe unterschiedliche Namen für Stationen verwenden kann.

Das ist da oben zu sehen. Genau, dann eben eine Geometriebearbeitung, dass man die Geometrien da aufeinander legen kann, hier unten dargestellt. Und dass man den Export und Deploy der Daten auf den Teilserver anstoßen kann.

Genau, Map-Putnik wird zum Editieren des Rendering-Styles verwendet. Da kann man dann eben in den Style-Regeln verschiedene Filter anlegen, die dann diese Attribute in den Daten entsprechend auswerten,

um eben z.B. diese Label-Position anhand der Attribute zu steuern. Genau, dieses angesprochene Web-Interface ist eine relativ einfache Anwendung. Man exportiert halt oben in Map-Putnik sich diesen Mapbox-DL-Style

und kann ihn dann anschließend im Web-Interface Patrick and Rob reinziehen. Dauert dann einen Moment und der Style wird dann deployed und der Server neu gestartet, sodass eben nach wenigen Augenblicken dann die Kachel mit dem neuen Stil ausgeliefert werden. Wie anfangs schon angesprochen ist für uns auch ganz wichtig, dass man auch Fachinformationen darauf referenzieren kann.

Die Streckentopologie, also die korrekte Abfolge der Station ermöglicht es, auch Aspekte mit Strecken- oder Kilometerbezug auf den Karten abbilden zu können.

Dabei gibt es grundsätzlich zwei verschiedene Arten von Referenzierung, einmal die topologische und die lineare. Die topologische Referenzierung ist immer an Feature gebunden, zum Beispiel, dass man einer Station gewisse Informationen zufügen kann, wie eine Passagierzahl oder eine Kante zwischen zwei Stationen, zum Beispiel den Infrastrukturbetreiber.

Dann gibt es noch die lineare Referenzierung, die es ermöglicht, beliebige Punkte auf dem Streckennetz abzubilden, zum Beispiel die Lage eines Bahnübergangs oder einen Abschnitt mit einer gewissen Geschwindigkeit. Aktuell erlaubt es unsere Datenbasis, aber nur relativ solche Informationen abzubilden.

Relativ ist eben, dass man in Prozentwerten praktisch angibt, auf welchem Abschnitt einer Kante eine Information gilt. Absolut wäre eben mit richtigen Kilometrierungen, da komme ich gleich nochmal darauf zurück,

genau ein Beispiel, wo die lineare Referenzierung jetzt schon eingesetzt wird, ist die Erfassung der Tunnel. Die werden über die lineare Referenzierung mit relativen Angaben auf den Kanten erfasst. Hier links sieht man eben, wie das Ganze dann in diesem Editor bearbeitet wird.

Und rechts sieht man dann, wie das entsprechend dann später auf der Karte aussieht. Da wird dann diese Kante entsprechend aufgesplittet und der Bereich, wo der Tunnel ist, dann entsprechend anders dargestellt. Zum Ausblick noch ein paar Ausblicke auf die nächsten Schritte, die wir in dem Projekt verfolgen.

Wie angesprochen, diese lineare Referenzierung ist halt ein primäres Ziel, damit man auch über Kilometrierungen und Streckennummern noch Daten abbilden kann. Beispiele wären zum Beispiel, dass man die Lage von Baustellen auf dem Streckennetz abbilden kann.

Wie gesagt, ist das im Moment nur über die recht grobe topologische Referenzierung möglich. Das große Problem ist halt hier auch wieder die Verfügbarkeit der Daten. Grundsätzlich kann man solche Daten aus USM übernehmen, da werden halt Streckennummern und Kilometrierungen erfasst.

In der Praxis ist das halt auch wieder das Problem mit der Vollständigkeit der Daten. Da rechts habe ich mal eine kleine Auswertung gemacht. Da symbolisiert jeder turkise Punkt im Grunde einen Kilometerstein, der in USM erfasst wurde. Das sieht man ganz gut in Deutschland auf den Hauptstrecken.

Da ist die Erfassung eigentlich ganz gut, das wäre ganz gut brauchbar. Auf den Nebenstrecken ist es dann schon nur stellenweise. Und im Ausland sind im Grunde gar keine Daten vorhanden. Und auch hier gibt es eben auch von den Bahnbetreibern keine entsprechenden Daten, die man da verwenden könnte. Ein weiteres Ziel ist, dass wir länderübergreifendes Routing auf diesen Daten machen.

Da sind keine größeren Anpassungen mehr notwendig. In der Schweiz geht das schon mit dem Traffi-Marsch-Portal. Genau, und die Datenaktualisierung. Man will halt die kontinuierlichen Änderungen am Schienennetz, die auch in USM dann nachgeführt werden, auch in unsere Daten übernehmen.

Das Problem ist eben, dass man von zwei verschiedenen Richtungen im Grunde die Änderung hat. Die Änderung aus USM und unsere manuellen Anpassungen macht es ein bisschen schwierig. Im Grunde ist der aktuelle Plan, dass man dann mit einem aktuelleren USM-Datensatz praktisch wieder so einen aggregierten Datensatz erzeugt.

Und dann redaktionell, manuell praktisch die Änderung aus dem neueren Datensatz in den produktiven Datensatz übernimmt. Vielen Dank für die Aufmerksamkeit und gibt es Fragen? Ja, erstmal Dankeschön.

So, und das Auditorium ist wieder gefragt. Danke für den Vortrag. Ich will dir an einer Stelle gleich widersprechen. Und zwar gibt es durchaus verfügbare Layer von den Bahnbetreibern für die Kilometrierung. Die bestehen meistens eben nicht aus einzelnen Punkten, sondern

in guter Verfügbarkeit hat man linienförmig einfach die offiziellen Streckendefinitionen. Und dann kann man als Attribut jeweils von der Linie einen Startenkilometer abgreifen und von da aus dann ausmessen. Also habe ich schon entwickelt, leider für meinen Chef und dadurch nicht open source.

Ja genau, also wenn es solche Datensätze gibt, dann hat man eben da auch so eine Knotenkantestruktur. Da ist dann praktisch für jede Kante Start- und Endkilometer definiert. Aber wie gesagt, in Deutschland gibt es eben für die Deutsche Bahn dann noch solche Daten. Aber in anderen Ländern wird es dann schwierig. Wie groß ist denn der Aufwand?

Nicht ohne Mikrofon. Wie groß ist denn der Aufwand, dass die Geometrien dann nachbearbeitet werden müssen? Also dass OSM die Bahngeometrien nicht stimmen quasi? Das Nachbearbeiten der Geometrien ist halt eben um die Darstellung zu optimieren.

Also wie zum Beispiel eben dargestellt, dass man auf niedrigen Zoomstufen dann parallele Strecken eben zusammen fasst und solche Sachen. Also für die Generalierungsstufen und dort ist es nötig, aber nicht allgemein der Datensatz, der ist an sich schon korrekt. Genau, das ist eben um die Darstellung zu optimieren.

Ich wollte bloß zu dem Punkt vorher. Muss man unterscheiden zwischen der rein geometrischen Kilometrierung, die man natürlich einfach selber rechnen kann, und zwischen der offiziellen Bahnkilometrierung, das ist was völlig anderes. Weil das kann sich durch Baumaßnahmen ständig verändern. Sie haben draußen die Schilder und die werden natürlich nicht ständig verschoben, wenn die Strecke sich ändern.

Wollte ich nur als kleinen Nebensatz ergänzen. Danke. Alexei Valikov, Deutsche Bahn. Auf Open Data Portal von Deutschen Bahn gibt es ein Streckennetz, was halbwegs offiziell von DB Netz zur Verfügung gestellt wird. Da sind in Linien geometrien, wie der Kollege gesagt hat, die Kilometrierungen.

Also da sind nicht die gemessenen Kilometrierungen, sondern da sind die echten Kilometrierungen. Und da gibt es auch ein Layer mit Kilometrierungen mit einem Abstand von einem Kilometer. Da sind, keine Ahnung, 35.000 oder so Punkte mit Kilometrierungsangaben.

Ich glaube, wir haben auch ein ähnliches Algorithmus entwickelt auf der Basis von diesen Daten. Wir haben bei relativ einfachen Algorithmus eine sehr gute Erfolgsrate, also vor allem bei dieser Referenzierung, also Streckenkilometer und Kilometer. Von 35.000 waren 20 Stück, also nicht 20.000, sondern 20 Stück außerhalb von sozusagen Toleranzbereich.

Also Daten gibt es, muss man auch gucken, was man damit machen kann. Ja, wie gesagt, also für die Deutsche Bahn gibt es entsprechende Daten. In der Schweiz eben dieser Datensatz vom Bundesamt für Verkehr,

aber in anderen Ländern wird es dann halt wirklich schwierig, da Daten zu finden. Und genau diese geometrische Kilometrierung, das ist im Grunde, was wir eben bei den Tunneln zum Beispiel jetzt im Moment machen, dass man praktisch einfach über die Länge der Geometrie da dann die Tunnel abbildet. Aber was wir eben suchen, ist wirklich diese bahninterne Kilometrierung,

dass man eben, wenn man von Kunden oder irgendwelchen Verkehrsunternehmen Daten bekommt, wo, wie gesagt, Baustellen oder sowas mit Kilometrierungen referenziert sind, dass man wirklich sowas dann auch auf diese Karten abbilden kann. Wo kann ich denn die Daten jetzt runterladen, die du da erzeugt hast?

Was geplant ist, sobald das Ganze live geht, ist, dass wir diesen Code, um das generalisierte Streckennetz zu erzeugen, dass wir das auf GitHub veröffentlichen. Die Daten an sich ist nicht geplant, das zu veröffentlichen, weil, wie gesagt, das ist halt speziell für unseren Anwendungszweck halt optimiert.

Das sind aber ja ODBL-Daten, auf denen ihr arbeitet und die ihr weiterverarbeitet, und deswegen müsstet ihr herausgeben. Ja, bin jetzt kein Jurist, aber soweit ich weiß, reicht es ja, wenn man praktisch den Code veröffentlicht, mit dem man solche abgeleiteten Daten erzeugt, wie gesagt.

Ja, das ist die Frage, wenn ihr den Source Code für die Mitarbeiter, die die manueller Arbeit gemacht haben, auch rausgebt. Aber da gibt es ja nicht so den Source Code für, weiß ich nicht, wie das funktioniert. Fragen wir mal den Juristen. Du wolltest, du wolltest doch.

Es gibt ja den Eisenmann-Atlas, also auch für EU und Deutschland und so weiter in gedruckter Form. Gibt es da auch den Austausch zwischen euch und denen? Also du kennst das Produkt? Nein, den Atlas kenne ich, aber mit dem Unternehmen, was da hinter steht,

haben wir jetzt nicht in Kontakt. Ok, die haben weniger Geodaten, aber die haben auch Kilometrierungen drin, also für ihre Betriebsstellen und Bahnen. Ja, aber die sind halt auch sehr auf gedruckte Karten spezialisiert. Also ich glaube, die hatten mal eine Zeit lang auch eine digitale Version,

was im Grunde auch nur so eine fertige Rastakarte war, aber aktuell glaube ich wird da ja noch nichtmals irgendwie das noch in digitaler Form vertrieben, sondern halt nur dieser gedruckte Atlas. Ok, danke. Also ich wollte zu dem Lizenzthema noch sagen, dass soweit ich das jetzt verstanden habe, oder das kann falsch sein, ist die manuelle Nachbearbeitung auf der Ebene des Produced Work

und deswegen würde ich sagen, dass … … in der Datenbank stattfindet. Nein, das ist nicht eine Frage, ob es in der Datenbank stattfindet, sondern ob es auf der Ebene der Gestaltung stattfindet. Und wenn es um Labelplatzierung und sowas geht, dann ist das definitiv nicht etwas, was von der ODIBL abgedeckt ist. Ich weiß natürlich nicht, ob da auch Aspekte drin sind, die tatsächlich Datenverarbeitung sind.

Ich denke mal, das war jetzt auch nicht in einer Diskussion hier, wenn wir Fragen an den Referenten haben, lösen wollen. Deswegen die Frage, gibt es weitere Wortmeldungen aus dem Plenum, die noch andere Gesichtspunkte behandeln?

Noch eine Frage zur manuellen Nachbearbeitung. Wie viel Aufwand ist denn da notwendig, so einfach geschätzt, erfahrungswert, um das eben, um aus der Generalisierung, die man automatisiert hat, eine schöne Darstellung für die verschiedenen Sungsstufen zu machen? Ja, einen konkreten Zeitaufwand kann ich da jetzt gar nicht so nennen.

Also man geht da ein bisschen gezielter vor, dass man, wie gesagt, sich irgendwelche größeren Bahnknoten anschaut, wo viele Strecken zusammenlaufen, dass man gezielt den Stellen das dann anpasst. Und da ist das dann auch eben wieder so ein iterativer Prozess, dass man da die Daten anpasst, dann schaut, wie sieht es auf der Karte aus,

und dann wieder das alles irgendwie ein bisschen zurechtdrückt, bis man eben so eine schöne Darstellung hat.