We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Ablösung proprietärer Kartografie-Software durch eine OpenSource -und OpenData-Lösung

00:00

Formal Metadata

Title
Ablösung proprietärer Kartografie-Software durch eine OpenSource -und OpenData-Lösung
Title of Series
Number of Parts
107
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Im Vortrag wird vorgestellt, wie die bisherige Lösung durch OpenSource-Software (QGIS, PostGIS) und OpenDaten (OpenStreetMap) abgelöst wird. Dabei galt es nicht nur eine technische Lösung zu finden, die es ermöglicht die Kartenbasis aus OSM-Daten zu bestücken und mit den Daten der BVG (Liniennetz, Haltestellen etc.) in einer gemeinsamen Datenbank zu kombinieren. Es mussten auch die hohen Ansprüche an die kartografische Gestaltung berücksichtigt werden. Der Vortrag stellt die Lösung vor, die in enger Zusammenarbeit zwischen der BVG und der WhereGroup entwickelt wurde und wirft insbesondere Schlaglichter auf die automatisierte Weiterverarbeitung der verschiedenen Datenimporte und die ebenfalls automatisierten Generalisierungsprozesse in der der PostGIS-Datenbank. Darüber hinaus wird vorgestellt wie mit umfangreichen Beschriftungs- und anderen Regeln innerhalb von QGIS aus den Rohdaten eine gute Stadt-Karte mit dem Schwerpunkt auf dem ÖPNV entsteht.
Keywords
SoftwareCONSULTANT <Datenbank>GeometrySource codeWeb pageAnbindung <Informatik>AutomationAdobe IllustratorSpatial data infrastructureData managementAudiovisualisierungDatabaseBlock (periodic table)SoftwareGeodesicBlogFirmwareStack (abstract data type)Scale (map)Level (video gaming)Component-based software engineeringData managementOpen sourceGeoinformationAutomationAdobe IllustratorPlane (geometry)HöheEnergiePlane (geometry)Web pageSmart cardComputer animation
TRAMO <Programm>DesktopDatabaseLINUXDatabasePostgreSQLProxy serverArchitectureServer (computing)SoftwareTable (information)GeometrySocial classCluster analysisData conversionPolygonScale (map)SVGBerechnungCluster samplingInformation privacySpeciesSurfaceGeometryInstanz <Informatik>Eigenvalues and eigenvectorsVerschneidungDatabasePoint (geometry)Maxima and minimaAnordnung <Mathematik>DepictionDatabaseServer (computing)Data storage deviceRectangleRaw image formatLocal ringVersion <Informatik>GeodesicList of anatomical isthmiScale (map)Cluster analysisFactorizationGoogleKanteRoute of administrationLeiste <Technik>Service (economics)PostgreSQLSphereSVGPoserInternetdienstArchitectureComputer animation
SoftwareScripting languageIntranetSpatial data infrastructureGeodesicSoftwareComputer data loggingPlane (geometry)Smart cardAbteilungSpatial data infrastructureProcess (computing)AutomationScale (map)Visualization (computer graphics)Level (video gaming)DepictionPhysical quantityDatabaseFunction (mathematics)CAN busSimilarity (geometry)Angular momentumInformationDigital signalProfessional network serviceAlgebraic closureData typeMusical ensembleOnline chatComputer animation
Scripting languageVector graphicsOnline chatModulformPoint of saleMusical ensembleLecture/Conference
Vector graphicsSurfaceBoom (sailing)Grand Unified TheoryParticle detector
RectangleCluster analysisParticle detectorScale (map)WordFunction (mathematics)InternetdienstWEBLagProcess (computing)DistanceWINDOWS <Programm>Data centerDatabase9 (number)Mobile appLecture/Conference
Transcript: German(auto-generated)
Ja, herzlich Willkommen zum zweiten Blog hier im Hörsaal 1. Wir werden uns jetzt ein wenig mit den kartografischen Themen befassen und der erste Vortrag von Luise und Robert hat die Ablösung einer proprietären Software,
ganz genau war es Adobe Illustrator, also gar kein Giz, durch einen Open Source Stack und ich würde mal sagen, ich war selber dabei im Projekt, das war eins der spannendsten QGIS-Projekte, die ich gemacht habe in der Wehr Group und ich bin gespannt, wie es ausgegangen ist.
Gut, ich hoffe, ich bin zu hören. Ja, herzlich Willkommen zu unserem Vortrag. Wir freuen uns, dass so viele Interesse zeigen. Ich muss auch sagen, das ist hier meine erste Fosges und ich fühle mich natürlich auch geehrt, dass ich gleich hier sprechen darf und mein Projektpartner und ich, wir werden euch heute eben dieses Projekt, an dem wir beide beteiligt sind,
vorstellen mit dem schönen Thema Ablösung proprietärer Kartografiesoftware durch eine Open Source und Open Data Lösung. Und als Erstes wollen wir uns einmal kurz vorstellen. Ich bin die Luise Leffmann, ich bin Kartografin bei der BVG und habe auch tatsächlich erst im letzten halben Jahr meinen Berufseinstieg gewagt,
habe vorher Geoinformation an der Berliner Hochschule für Technik studiert und habe jetzt bei der BVG eben dieses Projekt übernommen von meinem Vorgänger Sven Höß. Den wollte ich an dieser Stelle auch noch mal nennen, weil er eben dieses Projekt erst ins Leben gerufen hat und jetzt übergebe ich kurz an dich.
Ja, hallo, mein Name ist Robert Klemm und ja, ich muss gerade überlegen. So ja, eins, zwei, drei. Mein Name ist Robert Klemm und bin GISS Consulting und Entwickler bei der Firmware Group seit fünf Jahren. Mittlerweile habe ich auch ehemals an der Beuth Hochschule studiert. Jetzt ist ja die BRT und und bin quasi in dem Bereich Kartografie tätig.
Genau, die Kollegin hat es auch schon gerade erwähnt. Dieses Projekt gibt es ja auch schon sehr lange, sondern seit zwei Jahren. Und der andere Kartograf, der jetzt leider nicht mehr dabei ist, der Sven, mit denen habe ich das quasi ins Leben gerufen. Und wir hatten das dann über die Jahre durchzogen.
Das Projekt. Willst du weitermachen oder soll ich? Möchtest du weiter? Ja. Ja, kurz noch mal vorstellen. Die Firmware Group, auch hier in Hauptgang haben wir einen kleinen Stand. Können natürlich auch später Fragen gestellt werden. Und generell die die Firmware Group ist an vier Standorten
hier in Deutschland tätig, einmal Bonn als Hauptzentrale, Berlin, Hamburg und Freiburg. Und wir sind einer der größten Software Häuser hier in der GIT Branche in Deutschland und sind in verschiedenen Bereichen tätig. Genau. Und auf dem Bild sieht man die unsere Kollegen.
Ja, auf der anderen Seite sage ich natürlich auch gern noch mal was zur BVG. Die BerlinerInnen kennen sie wahrscheinlich BVG. Das sind die Berliner Verkehrsbetriebe, wo das G im Namen herkommt, ist eine andere Geschichte. Jedenfalls transportiert die BVG seit über 90 Jahren BerlinerInnen
durch die Großstadt. Und momentan sind das 15.800 Beschäftigte, die 700 Millionen Fahrgäste jährlich von A nach B transportieren an eine der 7600 Haltestellen in Berlin. Und die BVG betreut dann eben die Busse, die Straßenbahn und die U-Bahn in Berlin.
Die S-Bahn wird durch die deutsche Bahn gesteuert. Nur mal hier als Abgrenzung noch. Also die BVG, das sind alles die knallgelben Gefährte in Berlin. Das sind dann 910.100 Abfahrten pro Tag. Und die BVG-Webseite wird pro Jahr 21,3 Millionen mal abgerufen.
Nur um mal eine Größe zu nennen. Jetzt geht es aber zum Projekt, über das wir gern erzählen wollen. Und zwar geschieht das in Zusammenarbeit zwischen der BVG mit der Wear Group. Das heißt also, die BVG hat dieses Projekt ausgeschrieben und danach dann die Wear Group damit vertraut, gemeinsam ein Projekt zu entwickeln und bereitzustellen.
Und es geht um die Ablösung der bisherigen Kartografiesoftware, der BVG, durch eine modernere Lösung. Und die beiden wichtigsten Schlagworte sind hier eben Open Data, in dem Fall die OSM, die Open Street Map und die Verwendung von Open Source Software, in dem Falle dann QGIS.
Um darauf zu kommen, inwiefern diese neue technische Lösung eben nötig ist, stelle ich einmal die Kartografie innerhalb der BVG kurz vor. Die ist in der Abteilung der Fahrgastinformation angesiedelt. Und neben mir arbeiten zwei andere Kartografen mit daran und auch noch zwei Datenredakteure.
Und gemeinsam pflegen wir dann die topografische Stadtplansubstanz und auch die schematischen Netzspinnen. Das gehört ja alles irgendwie zur Kartografie mit dazu. Diese ganzen schematischen Pläne, die werden offensichtlich in Kendish, in Adobe Illustrator bearbeitet, werden aber jetzt hier in dem Projekt ausgeklammert. Bei uns geht es jetzt um die topografische Stadtplansubstanz,
die bisher mit einer Software namens Lorik bearbeitet wird. Lorik von Lorienne, das ist eine französische Software. Und man kann sich das Ganze eher als eine grafische Bearbeitungsoberfläche vorstellen. What you see is what you get. Also das Ganze hat halt keine Geodaten im Hintergrund.
Und das ist eben das große Problem. Und mit dem Ist-Zustand hat eben unsere Lorikartensubstanz drei Maßstäbe und man kann auch nicht andere Maßstäbe außer diesen Maßstäben auswählen, weil die alle händisch angefertigt wurden. Und tatsächlich gibt es auch nicht von jedem Bereich in Berlin alle Maßstabsebenen, weil diese Maßstabsebenen wiederum
an die kartografischen Medien, die daraus erstellt werden, gekoppelt ist. Und man muss auch echt sagen, dass die BVG-Kartografie sehr ästhetisch ist und eben über Jahre händisch gepflegt wurde. Aber das ist alles mit einem enormen Zeitaufwand verbunden. Und das Ziel der neuen technischen Lösung, die die Wear Group mit der BVG zusammen entwickelt.
Da gibt es drei wichtige Schlagwörter. Das ist einmal mehr Flexibilität, mehr Automatisierung und mehr Zeitersparnis. Und deswegen wird eben Lorik auf QGITS umgestellt und die BVG-Daten zukünftig mit den USM-Daten verschnitten. Ich habe ja an der Seite nochmal aufgelistet, welche kartografischen Medien eben aus diesen Substanzen erstellt werden.
Dazu aber an späterer Stelle mehr. Im Laufe des Projekts wurde dann eben konkretisiert, was diese neue technische Lösung für die BVG bringen soll. Und da sind die wichtigsten Komponenten eben, dass georeferenzierte Daten enthalten werden sollen, das Ganze über ein zentrales Datenmanagement gesteuert werden soll
und das Ganze eben auch auf verfügbaren, frei verfügbaren Geodaten der USM basieren soll. Und ein anderer wichtiger Punkt ist, dass eben die bisher bestehenden kartografischen BVG-Medien in einer ähnlich hohen Qualität auch in Zukunft dadurch ausgegeben werden sollen. Und zur technischen Seite sagt Robert jetzt gerne was.
Danke. Ja, bei dem Projekt haben wir eben viele Daten gehabt, auch von der BVG-Seite. Und wir haben natürlich am Anfang erst mal die Geodaten bzw. Daten gesichtet. Am Anfang war eben klar, dass wir die Hintergrundkarte auf USM-Daten aufbauen wollten
und wollten die dann mit den Fachdaten von der BVG und den externen Daten, GDFS-Daten oder die Standortdaten von öffentlichen Ämtern mit reinnehmen, also die von Fistbroker, von Berlin und von Brandenburg, die Geodaten. Und deswegen sehen Sie ja auch,
dass wir das als separaten Datentopf definiert haben. Alles andere kommt komplett aus USM. Und das sind die Rohdaten, die werden natürlich in den nächsten Arbeitsprozesse weiter veredelt, beziehungsweise weiter prozessiert. Da komme ich später nochmal drauf.
Ja, wie haben wir das denn aufgebaut? Wir haben quasi als Datenhaltung Brustkast genommen. Ganz unten sehen Sie nochmal die Datentöpfe. BVG, USM. Natürlich die Berliner Daten, die amtlichen Daten.
Und obendrauf über die Datenhaltung haben wir und wo dann über den Kugelserver dann über den Kugelserver die Dienste bereitgestellt werden, die dann für externe Anwendung genutzt werden können.
Das basiert alles komplett auf Docker bis auf die Datenhaltung. Das ist ein externer Server, der hoch verfügbar ist über den externen Dienstleister. Sonst die ganzen Anwendungsbeispiele, die laufen in einen Docker-Container bis auf der lokale Kugels client.
Genau, Benutzung Postgres 13 mit der neuesten aktuellen Postgres 3.2 Version. Ja, das war jetzt so ein bisschen die Systemarchitektur. Und jetzt müssen wir natürlich, das habe ich da vorher auch gesagt, jetzt müssen wir die Geodaten ja ein bisschen aufbereiten für die Kartografie,
bzw. für die Hintergrundkarte. Ich habe jetzt hier sehr abstrakt mal die Themen, Arbeitspakete zusammengefasst. Wir haben POS auf Interest, wir haben Grenzdaten, wir haben Brückendaten, Liniennetzdaten, Tunnel, BVG eigene Daten. Und zieht sich wie so ein roter Faden durch und natürlich auch sonstige Daten.
Ich nehme jetzt mal zwei raus und erkläre mal kurz, wie wir die Daten aufbereitet haben. Das Ziel, warum wir das machen, ist, wir wollten so wenig das in Kugels vorprozessieren. Wir hatten den Anspruch, dass wir was möglich ist in der Datenbank,
dass das vorberechnet wird. Genau. Bei den POS auf Interest ist es so, dass wir erst mal die Punktdaten normalisiert haben. Wir haben die quasi uns angeguckt, haben mit der BVG abgestimmt. Was wollen die haben? Was für POS brauchen sie? Wir haben dann doppelte Geometrien rausgerechnet
und haben dann mithilfe von Hilfstabellen unterschiedliche Geometrien verschnitten und normalisiert und haben natürlich die OSM-Tags, die wir nicht mehr brauchen, quasi rausgerechnet. Zum Schluss haben wir dann die Punktdaten
und die Flächen aus Flächendaten an Punktdaten generiert, dann wir im nächsten Schritt dann klustern konnten. Und über das Clustering konnten wir dann die Punktdaten eben zusammenrechnen, zusammenfassen, weil bei OSM ist es ja so, oder wissen wir ja alle, wenn mehrere Punktdaten von verschiedenen Typos an einer Stelle sind,
dann liegen die meistens übereinander. Und in der Kartografie will man ja nicht die Punktdaten, dass sie sich gegenseitig überlappen, sondern wir möchten das schön grafisch darstellen beziehungsweise auch nebeneinander anordnen. Und genau hier haben wir angesetzt und haben dieses Anordnen und Rausrechnen in der Datenbank quasi umgesetzt.
Das Ergebnis war, dass wir eine datenbankseitige Erstellung der Flächenobjekte haben mit einer optimierten Anordnungsdarstellung. Das heißt, wir haben aus den Punktdaten Rechtecke generiert. Über die Rechtecke haben wir eine Verschneidung gemacht in der Puskis-Datenbank und später haben wir aus den Flächen wieder einen Zentroid generiert und das mit einem SVG versehenden Kugel.
Das ist dann das Styling. Wie sieht denn das aus? Ich habe hier mal ein paar Bilder mitgebracht. Man sieht jetzt auch ganz schön auf der linken Seite. Das sind dann die Flächendaten. Das sind quasi alle Punktdaten, die aus einem Rechteck umgewandelt wurden.
Man muss dazu sagen, die Rechtecke orientieren sich an den Maßstab und anhand des Scales wird quasi der Faktor hoch und runter gerechnet. Sie sehen jetzt hier verschiedene Farben. Das ist bewusst, weil wir in einen Schritt alle Points Clustering-Punkte für alle Maßstäbe vorberechnen.
Das sieht man hier sehr gut, weil die Rechtecke variiert mit der Größe. Das liegt anhand des Maßstabes. Auf der rechten oder in der Mitte sehen Sie jetzt, da habe ich mal gesagt, gut, für den Atlas haben wir Maßstab 1,25.000. Wie sieht denn das überhaupt aus? Wie berechnet denn unsere Puskis-Datenbank die Anordnung?
Jetzt sehen Sie hier auch sehr gut. Vielleicht haben es auch schon einige erkannt. Das ist hier Atlashof. In der Mitte ist der S-Bahnhof. Und wir haben natürlich auf der BVG-Seite auch POIs, die wir darstellen wollen. Und die müssen natürlich schon für den Sachbearbeiter gut angeordnet werden. Das Ziel ist natürlich, dass der Sachbearbeiter zum Schluss
selber nochmal entscheidet, ist die Anordnung an der Stelle richtig oder muss sich das nochmal verschieben? Auf der rechten Seite sieht man dann quasi das Endergebnis in Kugis, wo dann die Flächen mit dem SVG, mit dem Styling versehen werden. So im Groben und Ganzen haben wir das da vorberechnet.
Und das gleiche Prinzip haben wir dann auch mit den Enthaltestellen-Signaturen gemacht. Das ist bewusst nicht zusammengemacht worden, weil vielleicht waren gestern vielleicht auch im Seminar mit der Generalisierung dabei. Wir haben immer noch das Problem, dass sich layerübergreifend die POIs oder die Flächen sich überlappen.
Deswegen haben wir hier einen Cut gemacht und gesagt, hier ist der Sachbearbeiter die letzte Instanz, Kontrollinstanz. Er entscheidet in Kugis, wo die Platzierung stattfindet. Ein anderes Problem oder was ich zeigen möchte, ist, wie haben wir denn die BVG-eigenen Liniennetzdaten verschnitten?
Wir haben zum größten Teil OSM-Daten genommen und natürlich BVG-eigene Daten genommen, zum Beispiel die eigenen Buslinien, Fährdaten, U-Bahn-Linien und Straßenbahnlinien und haben die dann verschnitten. In der Verschneidung wurde uns dann auch bewusst und auch klar, dass wir aus dem Thema des Datenschutzes
bestimmte Linienabschnitte rausrechnen mussten. Also wir mussten hier klar differenzieren, dass für die interne Ansicht, für die BVG sollen Linienabschnitte erhalten sein oder enthalten sein, die aber für den normalen Otto-Normalverbraucher nicht sichtbar sind. Deswegen gibt es hier nochmal eine Unterscheidung.
Das haben wir dann soweit aufbereitet und zusammengerechnet, dass wir dann verschiedene Linientypen verschnitten haben. Wie haben wir das dann beispielsweise mit den Haltestelleninformationen gemacht? Wir haben zum Beispiel die Haltestelleninformation oder Punkte von der BVG genommen und haben die mit einem einzelnen Closet-Point-Feature
zusammenverschnitten und haben dann später die Sachen zusammengerechnet. Ja, jetzt habe ich vieles über die kurze Datenbankprozessierung gesprochen. Wir haben in dem Projekt dann gesagt, der Ava-Sachbarbeiter kann selbst entscheiden,
welche Prozesse er steuern soll. Deswegen gab es innerhalb des Projektes dann einen Skid-Launcher, der dann genau die Prozessierung zwischen der Produktionsdatenbank und der OSM-Datenbank eben überwacht und verschneitet. Dann gibt es noch ein Logging dazu. Und später im Kugis-Projekt, hier ist ein Beispiel,
sieht man dann, wie das Endergebnis dann aussieht, wo dann der Sachbarbeiter dann die Geodaten bearbeiten kann, verschieben kann und auch noch mal modifizieren kann. Sieh gerade, hier fehlt... Nee, die kommen jetzt alle einzeln rein. Gut, dann übernehme ich jetzt wieder. Also was kommt also alles quasi aus Kugis raus und welche Medien der BVG werden sich dadurch Stück für Stück ändern?
Das habe ich hier einmal in drei Gruppen unterteilt. Die erste ist natürlich, das sind die analogen Medien. Hier habe ich mal ein paar Bilder reingelegt. Ja, hier sieht man zum Beispiel oben links in der Vitrine den Standortplan, der wird momentan noch händisch gezeichnet, soll dann eben abgelöst werden durch die neue Darstellung mit Open Street Map.
Dann haben wir den großen Wandstadtplan in einem Maßstab zu 1 zu 50.000. Wir haben verschiedene kartografische Flyer mit schematischen und topografischen Informationen, den Berlin-Atlas oder eben auch die Baustellen-Kartografie. Ach, da hast du mir noch eine neue Folie mit reingelegt.
Das sind dann jetzt schon die Darstellungen, die mit der neuen Software generiert wurden. Einmal zum Vergleich, genau. Da muss natürlich noch händisch einmal rangegangen werden. Aber hier kann man dann schon mal sehen, auf welchem Stand wir sind und was alles mit Automatisierung auch möglich ist. Dann haben wir auch noch die digitalen Pläne auch mal wieder hier im Vergleich.
Links die bisherige Software Lorik beziehungsweise die Visualisierung dieses Software und rechts die QGIS-Darstellung. Und als letzten Punkt, den ich auch noch mal nennen möchte, das ist der MapBender. Das ist ein browserbasiertes Tool, das quasi als WMS fungiert. Also wir Kartografinnen können die Karte in QGIS anfassen
und dann abteilungsweit über den MapBender diese Kartendarstellung an die BVG rausgeben. Das ist zum Beispiel wichtig, wenn schnell benötigte Baustellen Karten außerhalb der Kartografie erstellt werden müssen. Jetzt noch zum Abschluss, zum Fazit. Was sind also die großen Vorteile, die diese neue technische Lösung der BVG bringen?
Und das ist auf jeden Fall als erster Punkt zu nennen die Geodateninfrastruktur, die damit jetzt erstmals erstellt wird. Die Aktualisierung der Kartensubstanz, die dadurch weitaus erleichtert wird. Dadurch, dass eben alle Maßstabsehnen synchron miteinander agieren können. Es sind Referenzierungen in der Bearbeitung der Karte möglich.
Und eben wie angesprochen, der MapBender, der als internes WMS funktionieren kann. Und der wahrscheinlich wichtigste Punkt ist, dass diese neue Lösung technisch eben erweiterbar ist. Und wir haben schon viele Wünsche und Ideen auf beiden Seiten, die wir fleißig sammeln. Auch innerhalb der BVG aus verschiedenen Abteilungen höre ich Wünsche, schreibe sie mir auf.
Und genau, damit wird die BVG-Kartografie auf jeden Fall zukunftssicherer, erweiterbarer. Ja, genau. Wenn du nichts mehr hinzuzufügen hast, würde ich sonst zu den Fragen überleiten? Oder hattest du noch was?
Also, was man noch kurz sagen kann. Die BVG hat jetzt dadurch die Chance, eine zentrale GDI oder Geodateninfrastruktur zu nutzen, die dann fachbereichübergreifend nutzbar ist. Und die BVG freut sich natürlich jetzt eigentlich eine Puskastatmark zu nutzen. Da bin ich happy.
Ja, Luise, Robert, toller Vortrag. Ich bin beeindruckt, was daraus geworden ist. Und wir haben ein paar Fragen aus dem Chat.
Und die gehen immer auf die Daten. Also zwei Fragen. Die Fragen, warum ihr denn nicht basemap.de oder die Berliner lokalen ADCIS-Daten verwendet habt für das Projekt, und warum OSM und ob OSM als Screenshot genutzt worden ist oder als Vektordaten, fragt ein weiterer Zuhörer.
Ich habe es jetzt so verstanden, dass ich die Vektordaten benutze von OSM. Die Frage war, ob ihr das als Screenshot verwendet, die OSM-Daten. Was immer das sein soll. Nein, wir haben Datenimport. Das ist Snapshot.
Aber wir benutzen OSM-Daten und die werden über diesen Script Launcher nach Bedarf individuell importiert. Und durch die Import, da sind wir jetzt nicht mehr darauf eingegangen, gibt es eine Change Detection, die genau die Änderung, die der Sachbearbeiter durchführt, noch mal abgleichen mit den frischen OSM-Daten.
Man hat jetzt auch sehr gut gesehen in der Karte. Vielleicht ist es aufgefallen, da ist noch die alte Tramlinie drin. Die alte Schleife. Hier sieht man das sehr gut. Vielleicht kriegen wir ein größeres Bild. Und die werden natürlich mit OSM-Daten abgeglichen.
Und das wäre dann im nächsten, in der Change Detection fällt es natürlich auf. Und da wird der Sachbearbeiter dann sehen, an dieser Stelle haben sich nämlich die Vektordaten verändert. Und das kommt aus OSM. Und die politische Daten waren eigentlich kein Thema, großartig. Amtliche Daten waren die Badestellen.
Das, was man gesehen hat. Und die öffentlichen Toiletten. Die kommen von den amtlichen, aber Aktesdaten war kein Thema. Vielleicht wird das in der Zukunftsseite ein Thema werden. Aber zum Projektstart war das keine Anforderung. Alles klar. Habt ihr denn im Publikum noch Fragen an die beiden?
Also wir sind gut in der Zeit. Wir können einige Fragen beantworten. Dankeschön. Werden bei Bedarf auch aktualisierte Daten an die OSM-Community zurückcontributed? Also wenn ihr jetzt feststellt, da sind veraltete Daten.
Gibt es da irgendwie ein Team? Oder hat man sich da Gedanken gemacht, dass man bei ihr auch die OSM-Daten nutzt? Dass dann eben dementsprechend aktualisiert wird? Ich könnte gut ruhig kurz was dazu sagen. Also das sind auf jeden Fall Gedanken, die wir uns auch schon gemacht haben. Ob wir vielleicht sogar den Weg gehen wollen, dass wir die BVG-Änderungen im Liniennetz oder sonst was haben.
Dass wir auch erst, nicht nur BVG-interne Sachen, sondern wenn wir halt merken, dass in der OSM irgendwas veraltet ist. Dass man vielleicht sogar erst in die OSM geht. Und dann dadurch die Hintergrundkarte aktualisiert.
Statt eben selbst auf der eigenen Oberfläche nur die Daten zu halten. Also es sind Gedanken, da haben wir jetzt noch nicht feste Prozesse festgelegt. Aber ja. Das ist auf jeden Fall vorgesehen. Und die Karte, das haben wir gar nicht richtig gesagt. Die sollte auch für Barabandenburg dienen. Momentan haben wir den Bereich ein bisschen verkleinert.
Aus personalen Gründen natürlich. Und das heißt, die Change Detection läuft jetzt nur für Berlin und den Randbezirk. Also das, was die BVG gerade abdeckt. Zukünftig soll natürlich auch, ich sage jetzt mal, mehr zur polnischen Grenze oder ganz Land Brandenburg als Hintergrundkarte dienen.
Und da würde das natürlich dann genau reinspielen, dass im bürschländlichen Raum auch die Daten aktualisiert werden in der OSM. Okay, dann haben wir jetzt hier oben noch eine Frage. Genau, vielen Dank. Sehr spannend. Ich hätte zwei Fragen. Eine ist, ob es schon Feedback gab von den Sachbearbeiterinnen. Also wie das jetzt schon in der Nutzung ist, was da schon so zurückgekommen ist.
Und dann noch die Frage, ob es auch live möglich ist, verschiedene Besuchsmaßstäbe abzuleiten mit der Verdrängung. Oder sind das eben doch auch vorprozisierte Maßstäbe, die es dann auszuwählen gilt? Ja, vielleicht zum ersten Thema, wie der Stand gerade ist, ob wir da schon Feedback haben. Tatsächlich noch nicht.
Wir sind gerade mit dem Projekt so weit, dass jetzt die Migration ansteht. Also alle Funktionen wurden quasi von der Wear Group eingebaut. Und die nächsten Schritte sind jetzt eben, dass wir als Kartografinnen, wenn es dann möglich ist, üben mit dem neuen Programm umzugehen und Arbeitsprozesse damit entwickeln. Genau.
Was war der zweite Teil der Frage? Mit den Bezugsmaßstäben, ob die auch frei rechenbar sind oder ob die alle vorprozisiert in der Datenbank vorliegen. Fass dich kurz, Robert. Ich fass mich ganz kurz. Es gibt Maßstäbe, die sind vorberechnet. Es sind genau fünf. Und darüber hinaus bis eine Million, das ist dann frei.
Da ist das klassisch, so wie man das kennt, vom WebGIS. Also jetzt können wir noch zwei schnelle Fragen machen. Ja, ich wollte wissen, nochmals Change Detection. Du hast es angerissen. Also ich habe das vorhin so verstanden. Da findet dieses Clustering statt. Und dann wird da so Verdrängung gemacht für verschiedene Maßstäbe. Haben wir ja gesehen mit den Rechtecken. Dann kann da der Sachbearbeiter oder die Sachbearbeiterin irgendwie das schön arrangieren,
sodass es irgendwie auch passt. Und jetzt kommt so eine Change rein von USMA, den Poi, den gibt es jetzt gar nicht mehr. Und das obere linke Feld von den vier Rechtecken wird dann dadurch irgendwie leer. Kannst du da noch mal zwei Worte sagen, wie das dann sozusagen die manuelle Nachbearbeitung von so einer Change, was da passiert?
Genau, also bei den Change kann das kurz... Ach nee, machen wir es so. Genau, bei dem Change ist es so, dass wir zwei Datenbanken haben. Und die Change Detection läuft quasi im Hintergrund. Denn Kugis hat der Sachbearbeiter immer zwischen den zwei Layern zu wechseln und kann die Änderung über die alte Änderung überschrieben,
also quasi der alte Stand überschrieben mit der neuen Änderung. Ja, das tut mir leid. Wir müssen jetzt die Fragen an der Stelle ab. Verlager nach draußen. Also die Wehrgruppe und Luise sind ja da. Und wenn ihr noch weitere Fragen habt, geht zum Wehrgruppestand und fragt die beiden Löcher an den Bauch. Vielen Dank.