OKSTRA®-Werkzeug
Release Notes
Zurück zur Übersichts- und Downloadseite des OKSTRA-Werkzeugs.
| Datum | Änderung |
| 22.06.2023 | Veröffentlichung korrigierte Version 1.5.4.1 |
| 22.06.2023 | Aufgrund eines Fehlers bei der Zusammenstellung des OKSTRA-Werkzeugs wurde eine ungültige Fassung des XML-Datenschemas für die OKSTRA-Version 2.021 benutzt. Das Schema wurde ausgetauscht. Bitte installieren Sie umgehend die neue Version des OKSTRA-Werkzeugs. Wir bedauern eventuelle Unannehmlichkeiten. Signatur des Problems: Beim XML-Export mit dem OKSTRA-Werkzeug werden korrekte Daten geschrieben, aber die Schemavalidierung meldet Probleme. |
| 26.05.2023 | Veröffentlichung Version 1.5.4.0 |
| 23.05.2023 | Die OKSTRA-Version 2.021 wurde veröffentlicht. |
| 10.05.2023 | Ab der PostgreSQL-Version 13 wird ein neues Default-Format bei der Authentifizierung benutzt (scram-sha-256 ersetzt md5). Dises Protokoll wird von der Komponente npgsql in der bisher benutzten Version 2.1.3 nicht unterstützt. Ein Umstieg auf die neueste Version von npgsql scheitert daran, dass darin mittlerweile .NET Core benutzt wird, was die Oklabi basierend auf .NET Framework 4.8 nicht verwenden kann. Folgende Möglichkeiten bestehen zurzeit, mit dieser Situation umzugehen:
|
| 10.05.2023 | Aufgrund der zeitlich limitierten Unterstützung für .NET Framework 4.8 durch Microsoft wurde eine Umstellung auf .NET Core Version 6 vorgenommen. Das gelingt zurzeit nur mit Visual Studio 2022. Hierfür wurden mehrere grundlegende Eingriffe vorgenommen:
Die C++ Bibliotheken sind hiervon nicht betroffen. Anzupassen waren sämtliche Bibliotheken, die in C# oder managed C++ implementiert sind. |
| 04.05.2023 | Im Testdatengenerator wurde nicht brücksichtigt, wenn eine Relation symbolisch darzustellen war. Die notwendigen Aktionen hierfür wurden ergänzt. Bei der fachlichen Prüfung derartig erzeugter Daten wurden Fehler behoben. |
| 14.04.2023 | Die Anwendung OKSTRA-Skript wurde erweitert, um auch mit Daten im SQLite-Format umgehen zu können. Es wurden dafür neue Parameter eingeführt. Verschiedene Einstellungsmöglichkeiten wurden verallgemeinert, z.B. die Geometriedimension, um diese Setzung auch für den XML-Export zu ermöglichen. Die Dokumentation von OKSTRA-Skript wurde überarbeitet. |
| 14.04.2023 | Die Online-Dokumentation wurde erweitert um Hinweise, wie man mit externen Werkzeugen (z.B. QGIS) die grafische Anzeige von OKSTRA-Daten vornehmen kann. |
| 11.04.2023 | Die Angabe von mehreren Gitterdateien für eine Koordinatentransformation wurde nicht korrekt erkannt. An der Analyse der Oklabi-Konfigurationsdatei wurden Verbesserungen vorgenommen. |
| 28.02.2023 | Sobald eine entsprechende Gitterdatei vorliegt, kann nun zwischen verschiedenen Höhensystemen transformiert werden. Zum gegenwärtigen Zeitpunkt wird nur die Transformation zwischen DHHN92 und DHHN2016 unterstützt. Dabei kommt eine gewandelte Gitterdatei zum Einsatz, deren Vorlage von der Bezirksregierung Köln für die Komponente HoeTra erstellt wurde. |
| 23.12.2022 | Veröffentlichung Version 1.5.3.0 |
| 22.12.2022 | Die Open Source Komponenten in der Oklabi wurden aktualisiert, da keine Versions-Ressourcen bei den DLL-Bibliotheken vorhanden waren. Das führte zu Problemen mit Installationswerkzeugen. |
| 17.12.2022 | Der XML-Export von Volumengeometrie schlug fehl in den OKSTRA-Versionen 2.x, wenn nicht die Expressgeometrie-Darstellung aktiv war. Die Komponenten der Geometrie (begrenzende Flächen) wurden nicht korrekt ausgelesen und daher nicht exportiert. |
| 17.12.2022 | Das WKT-Format für Volumenkörper wurde stets leer zurückgegeben, da es einen Fehler bei der Geometrieaufbereitung gab. Betroffen war z.B. die Übertragung in eine Datenbank. |
| 17.12.2022 | Die Transformationslogik für Koordinaten funktionierte nicht korrekt bei Volumengeometrie. Es kam zu unverständlichen Fehlermeldungen. |
| 06.12.2022 | Bei der Beschaffung der Schlüsselwerte zu einer Schlüsseltabelle mit numerischen Schlüsseln, wie es in älteren OKSTRA-Versionen noch möglich war, trat ein Fehler aufgrund einer falschen Abfrage auf. Dadurch konnte es zu einem Abbruch der Anwendung kommen. |
| 05.12.2022 | Die Transformation von Koordinaten benutzt Hilfsmittel aus dem GDAL-Paket. Durch die Einführung der neuen GDAL-Version 3.5 kam es zu Berechnungsfehlern aufgrund der Reihenfolge der Koordinatenwerte. Die neuere GDAL-Version beachtet hier genauer die Definitionen aus dem EPSG-Katalog als die zuvor benutzte GDAL-Version 1.11. Das Problem trat nicht bei allen Bezugssystemübergängen auf. Betroffen war z.B. der Übergang von EPSG:2398 (Pulkovo-Krasskovski 42-83) nach EPSG:4326 (WGS84). Dabei kam es zu keiner Fehlermeldung während der Berechnung, sondern lediglich zu völlig falschen Resultaten. Andere Übergänge (z.B. UTM32 nach WGS84) wurden korrekt gerechnet. |
| 17.10.2022 | Veröffentlichung Version 1.5.2.3 |
| 19.09.2022 | Die Verallgemeinerungen im Zusammenhang mit der Version der Fachbedeutungslisten (siehe auch Eintrag vom 10.06.2022) führten bei Versionen größer als 5.x zu einem Auslesefehler. Die Versionsanalyse wurde verallgemeinert. |
| 15.09.2022 | Während des Ladens von XML-Dateien können transiente Fachobjekte entstehen, z.B. Schlüsseltabellen und komplexe Datentypen für die Verarbeitung von Koordinatenreferenzsystemen. Diese Fachobjekte wurden bei der Nachbehandlung nicht sauber aus dem Datenbestand wieder entfernt. Das führte z.B. bei einer späteren Profil-Prüfung zu Fehlermeldungen. Die nicht mehr benutzten Fachobjekte werden nun entfernt. |
| 18.08.2022 | Beim Schreiben in eine Datei auf einem sehr schnellen System konnte es zu Kollisionen bei nebenläufigem Zugriff kommen. Hier wurde eine entsprechende Absicherung eingebaut. |
| 01.08.2022 | Sämtliche Komponenten der Oklabi, die das .NET Framework benutzen, wurden auf die Version 4.8 umgestellt. |
| 27.07.2022 | Ein großer Teil der Open Source Komponenten in der Oklabi wurde auf aktuelle Versionen migriert. Das betrifft die Komponenten sqlite, proj, libspatialite, geos, gdal. Das hat auch Auswirkungen auf die verteilten Ressourcen. Bitte beachten Sie auch die Oklabi-Dokumentation. |
| 01.07.2022 | Veröffentlichung Version 1.5.1.1 |
| 01.07.2022 | Bei der Datenbankübertragung mit einer Steuerdatei konnte es zu Abbrüchen kommen, weil die Datenbankverbindung nicht korrekt geöffnet wurde im nebenläufigen Betrieb. |
| 24.06.2022 | Veröffentlichung Version 1.5.1.0 |
| 24.06.2022 | Umstellung der OKLABI-Bibliotheken auf Microsoft Visual Studio 2019. Eventuell muss die passende Laufzeitumgebung installiert werden, bitte wenden Sie sich bei Problemen an einen Administrator. |
| 24.06.2022 | Einstellung der 32-Bit Version des OKSTRA-Werkzeug |
| 10.06.2022 | In der Oberfläche des OKSTRA-Werkzeug und OKSTRA-Profileditor wurden Aktionen integriert, mit der man beide Anwendungen gegenseitig öffnen kann. |
| 10.06.2022 | Aus historischen Gründen war bisher möglich, eine maximale Version von 5.9 für die Fachbedeutungslisten anzugeben. Hier sind nun Angaben bis zur Version 99.9 möglich (Unterversion stets einstellig) |
| 22.04.2022 | Das Menü für die Fachbedeutungslisten wird nun zuerst über die Bundesländer und danach über die vorhandenen Versionen der FB-Listen organisiert, um die Suche zu vereinfachen. Bei den Koordinatenreferenzsystemen kann man (sofern vorhanden) im Menü den EPSG-Code mit anzeigen, was über einen Konfigurationsparameter gesteuert wird. |
| 06.04.2022 | Bei der Übertragung von Daten in eine SQL-Datenbank werden nun alle Fachobjekte ausgelassen, die ausschließlich Bezug zum (internen) Geometrieschema besitzen. |
| 04.04.2022 | Aufgrund der strukturellen Veränderung der Teilabschnitte (Entfall der enthaltenen Straßenpunkte) musste die Funktion zur Bestimmung der Kennung von Teilabschnitten angepasst werden. Hierdurch konnte es zu Abbrüchen kommen. |
| 29.03.2022 | Die Wrapper für .NET und Java benutzen die Referenzierung von Schnittstellenobjekten, um die Fassaden mit den C++ Objekten zu verknüpfen. In hochgradig nebenläufigen Anwendungen (z.B. bei der Datenbankübertragung) konnte es zu Kollisionen kommen. Ausnahmen werden in solchen Fällen nur noch erzeugt, wenn es ausdrücklich erforderlich ist, die Vorgehensweise bei der Dereferenzierung wurd entspannt. Hierdurch werden u.a. irreführende Meldungen vermieden. |
| 18.03.2022 | Im Testdatengenerator konnte es vorkommen, das vorgegebene Kardinalitäten verletzt wurden, wenn inverse Relationen erzeugt wurden. Am Testdatengenerator wird weiterhin gearbeitet. |
| 17.03.2022 | Die OKLABI-Konfigurationsdatei ging nicht auf den Steuerparameter für die Nebenläufigkeit ein, das wurde ergänzt. Des Weiteren wird nun per Vorgabe die Nebenläufigkeit aktiviert, weil das umgekehrte Verhalten häufiger Probleme bei Anwendern verursacht hat. |
| 11.03.2022 | Wenn bei der Anwendung OKSTRA-Skript ein einteiliger Parameter als letzter Parameter in der Ausrufliste stand, wurde der Parameter überlesen. Es wurden neue Parameter ergänzt, die Dokumentation wurde angepasst. Bevor ein neuer Ladevorgang gestartet wird, wird nun ein eventuell bereits geladener Datenbestand abgeräumt, um Speicher zu sparen. |
| 07.03.2022 | Nach dem Laden von XML-Dateien muss die interne Darstellung der Geometrie bearbeitet werden. Dieser Vorgang wurde auf nebenläufige Verarbeitung umgestellt. |
| 28.02.2022 | Basierend auf der Konfiguration der OKLABI kann Geometrie im Expressformat dargestellt werden, was bei der Übertragung in eine Datenbank nicht korrekt berücksichtigt wurde, es kam zu einem Abbruchfehler. |
| 31.01.2022 | Ein wiederkehrendes Problem bei Datenlieferungen ist die fehlerhafte Angabe des Koordinatenreferenzsystems. Hier wurde die Möglichkeit geschaffen, das Koordinatenreferenzsystem auszutauschen ohne Ausführung einer Transformation. |
| 31.01.2022 | Im OKSTRA-Werkzeug wurde eine neue Aktion eingebaut, mit der die Zuweisung eines Höhensystems ermöglicht wird. |
| 31.01.2022 | Ein neues Informationsfeld wurde eingeführt, um die Intormation über die Metadaten zum geladenen Datenbestand anzuzeigen. Eine Editiermöglichkeit besteht hier noch nicht, diese soll folgen. |
| 31.01.2022 | Zur flexiberen Anpassung der Umgebung an die Einsatzbereiche wurden neue Einstellungparameter eingeführt. Betroffen sind die Bereiche der SQL-Datenbankübertragung und die Anzeige der Metadateninformation im OKSTRA-Werkzeug. |
| 28.01.2022 | Verschiedene Optimierungen zur Beschleunigung der Übertragung von OKSTRA-Daten in eine SQL-Datenbank wurden eingebaut. Betroffen sind in einem ersten Ausbauschritt die Vergabe von Datenbankidentifikatoren und das Format der Zwischentabelle für die Relationen. |
| 17.01.2022 | Die Datenbankübertragung von Daten, bei denen Datum-Attribute vom Typ Uhrzeit beteiligt waren, schlug fehl. Es muss ein timestamp-Wert formatiert werden für die Übertragung in eine PostgreSQL-Datenbank, es wurde jedoch nur die Uhrzeit angegeben. |
| 11.01.2022 | Der Export eines Datensatzes in eine SQLite-Datenbank schlug fehl, weil bei einem Iterator ein fehlerhafter Zugriff eine Endlosschleife auslöste. Diese Situation wurde bereinigt. Betroffen waren Schlüsseltabellen mit einer ungeraden Zahl von Spalten. |
| 08.10.2021 | Veröffentlichung Version 1.4.0.08 |
| 13.09.2021 | Das Auftreten von XML-Schemafehlern, die bei der Validierung vor dem Einlesen von XML-Dateien erkannt werden, wird nun an den XMLEingabeKonverter gemeldet, der das Einlesen gestartet hat. Über die neue Schnittstelle GibAnzahlSchemafehler() kann bestimmt werden, ob Fehler aufgetreten sind oder nicht. |
| 29.07.2021 | Eine Datenbanktabelle (_kopfdaten_), die zu technischen Zwecken dient, wurde um zwei Spalten erweitert. |
| 28.07.2021 | An der Schnittstelle AusgabeKonverter wurde die Möglichkeit ergänzt, die Anzahl der Geometriedimension auf 2 oder 3 festzulegen. Dafür wurde die neue Schnittstelle SetzeDimension() eingeführt. |
| 22.07.2021 | Je nach Einsatzbereich kann es vorkommen, dass unbekannte Fachbedeutungen keinen fachlichen Fehler darstellen. Daher wurde für die Objektarten Symbol und Beschriftung die Möglichkeit eingeführt, Fehler bei der Fachbedeutungsprüfung zu ignorieren. |
| 07.07.2021 | Veröffentlichung Version 1.4.0.05 |
| 05.07.2021 | Ein Abbruchfehler beim Entladen von Daten aus fehlerhaften XML-Importdateien wurde beseitigt. |
| 25.06.2021 | Veröffentlichung Version 1.4.0.04 |
| 24.06.2021 | Die neue Klasse Kommunikationskanal wurde eingeführt. Unter Ensatz des boost Paketes werden Sockets benutzt, um zwei Anwendungen miteinander kommunizieren zu lassen. Bitte informieren Sie sich im Programmierhandbuch über weitere Details zur Verwendung der neuen Funktionalität. |
| 02.06.2021 | Bei der Berechnung der Bounding Box für einen Vollkreis wurde eine zu kleine Ausdehnung ermittelt. Dadurch wurde z.B. in der SVG-Darstellung eine falsche Größe angenommen. Kreise und Splines werden nun interpoliert, um die Bounding Box zu ermitteln. |
| 05.05.2021 | Die Namen der Protokolldateien beim Austausch mit Datenbanken wurde um einen Zeitstempel im Namen erweitert, um Kollisionen zu vermeiden. Die Liste für die Auswahl des Datenbankschemas wurde überarbeitet. |
| 05.05.2021 | Veröffentlichung Vorabversion 1.4.0.02 |
| 04.05.2021 | Eine Veränderung bei der Steuerung von Ausnahmen während des Ladens von XML führte zu Problemen beim Multithreading. Das Verhalten wurde auf den vorherigen Stand gesetzt. |
| 03.05.2021 | Veröffentlichung Vorabversion 1.4.0.01 |
| 30.04.2021 | Bei fehlerhaft aufgebauter Geometrie konnte nach einer Migration in die OKSTRA-Version 2.016 bei späterer Ausgabe der Daten im XML-Format ein Abbruchfehler auftreten. |
| 29.04.2021 | Ein Lesefehler trat auf, wenn für eine String-Eigenschaft eine maximale Textlänge im OKSTRA-Datenmodell vereinbart wird, wodurch es zu einem Abbruch kam. |
| 28.04.2021 | Die unterschiedliche Systemzeichenkodierung unter Windows und Linux führte dazu, dass Koordinatenreferenzsystememe in Profilen nicht gefunden wurden. Dasselbe konnte geschehen mit Profilnamen, die in XML-Dokumenten genannt werden. |
| 23.04.2021 | Beim Ausgaben von OKSTRA-Daten wird nun am Ende der Datei eine Prüfsumme eingetragen (Verfahren SHA256). Eine neue Methode zum Testen der Prüfsumme wurde in der Klasse Eingabe eingebaut. Bekanntes Problem: die Prüfsummenvalidierung schlägt fehl bei komprimierten Daten (gzip). |
| 22.04.2021 | Auf relativ langsamen Systemen kam es zu Konflikten im Multithreading-Betrieb beim Laden, wenn der Schemaname einer Objektart erfragt wurde. Eine entsprechende Absicherung wurde ergänzt. |
| 20.04.2021 | Bei der Ausgabe der XML-Metadaten kann nun gesteuert werden, ob die Ausgabe der Version des herstellenden Systems oder nur die Bibliotheksversion der OKLABI enthält (im Element preprocessor_version) |
| 19.04.2021 | Es wurden neue Einstellungsparameter ergänzt, die Ausgabe der Bibliotheksversion betreffend sowie für den geplanten neuen Kommunikationskanal. |
| 16.04.2021 | Beim Einlesen einer Steuerdatei für eine Datenbankoperation wurde der Name des Datenbankschemas nicht übernommen |
| 13.04.2021 | Die Angabe der Bounding Box in einer OKSTRAXML-Datei erfolgte im veralteten Format als coordinates-Element. Das Format wurde umgestellt auf die Angabe der Eckpunkte. Ferner wird nun das Koordinatenreferenzsystem auch an der BoundingBox ausgegeben, wenn es gesetzt ist. |
| 13.04.2021 | Bei der Ausgabe einer Linie als Linestring werden Doppelpunkte ausgespart. Dadurch konnte eine entartete Linie mit nur einem Punkt entstehen. Dieser Fall trat auch auf, weil der Koordinatenvergleich zweidimensional erfolgte und die betroffenen beiden Punkte sich nur in der Höhe unterschieden. |
| 09.04.2021 | Veröffentlichung Version 1.3.0.99 |
| 01.04.2021 | Ungültig im XML-Format dargestellte Geometrie konnte dazu führen, dass es einen Abbruchfehler gab. Die Geometrie wird gemeldet und geht nun beim Laden verloren. |
| 08.03.2021 | Meldungen konnten verloren gehen, wenn die Zuordnung des Ausgabekanals über die Thread-Kennung erfolgt. Durch die Einführung einer Kanalnummer kann man nun eine Zuordnung wieder herstellen. |
| 10.02.2021 | Der Testdatengenerator vernachlässigte die Erzeugung von Pflicht-Objektarten, wenn diese nicht bereits mit angelegt wurden. Hier wurde ein zweiter Durchlauf ergänzt, um die vom Profil verlangten Fachobjekte anzulegen. Im Verlauf der Arbeiten wurde die Pflege der Fortschrittsanzeige verbessert. |
| 08.02.2021 | Die Umstellung auf das HTTPS-Protokoll bewirkte Fehlermeldungen bei der Validierung von Profildateien. Diese Meldungen waren vermeidbar, weil Schemaversionen durchprobiert wurden anstatt korrekt den Dateiheader zu lesen. Die Meldungen waren meist unschädlich aber irreführend, konnten aber auch Abbrüche bewirken. Dieses Verhalten tritt nun nicht mehr auf. |
| 01.02.2021 | Veröffentlichung Version 1.3.0.96 |
| 29.01.2021 | Beim Laden von Daten aus der Version 1 kam es zu einem Abbruch, weil parallele Threads gleichzeitig dieselbe Ressource beanspruchten. |
| 28.01.2021 | Siehe auch Eintrag vom 22.12.2020. Es wurde ein weiterer Fehler in der Auswertung des Profils entdeckt und behoben. |
| 26.01.2021 | Einige Objektarten besitzen Geometrie, die sich berechnen lässt (z.B. Strassenpunkt oder Achse). Die Schnittstelle HatGeometrie an der Klasse Objektart wurde erweitert, damit man erkennen kann, ob es berechnete Geometrie dafür gibt. In diesem Fall wird nun bei der Datenbankübertragung auch die berechnete Geometrie mit übernommen. |
| 26.01.2021 | Das OKSTRA-XML-Format sieht vor, dass man Relationen auch durch Angabe einer fachlichen Kennung (z.B. beim Abschnitt) ausdrücken kann. Im Zusammenhang mit Verwaltungsbezirken fiel auf, dass beim Laden von Daten die Identifizierung des konkreten Objektes zu einer Kennung nicht funktionierte. |
| 22.01.2021 | Aufgrund eines Fehler bei der Formatwandlung während der Ausgabe von Daten mit einem Profil wurden manche Zahlen verkürzt ausgegeben. Der Fehler trat auf, wenn das Profil Null Nachkommastellen für eine Gleitkommazahl forderte. |
| 22.01.2021 | Die Interpolation von Liniengeometrie mit gerkümmten Anteilen (Spline, Kreisbögen) funktionierte nicht bei der Übertragung in eine Datenbankdarstellung (PostGIS und SpatiaLite). Die Schnittstelle Interpoliere an der Klasse Geometrie wurde in allen Schnittstellenwrappern nachgerüstet. |
| 12.01.2021 | Veröffentlichung Version 1.3.0.95 |
| 22.12.2020 | Wenn in einem Profil innerhalb von komplexen Datentypen Änderungen vereinbart werden, muss eine Pfadanalyse ähnlich wie bei Xpath-Ausdrücken vorgenommen werden. Hierbei traten Fehler auf, wenn derselbe komplexe Datentyp mehrfach vorkam. Eine Auswirkung davon war, dass Profildefinitionen nicht korrekt im Editor dargestellt und bei der Prüfung von Daten nicht richtig beachtet wurden. |
| 19.11.2020 | Für Punktobjekt und Streckenobjekt sowie ASB_Datum wurden Korrekturen bei der Migration durchgeführt. |
| 05.11.2020 | Die Darstellung der Geometrie beim Laden von XML enthielt aufeinanderfolgende identische Punkte in Linien (ein Relikt des alten OKSTRA-Geometriemodells). Diese verdoppelten Punkte werden nun beim Laden reduziert. |
| 09.10.2020 | Bei der Migration von Fachobjekten wurden Korrekturen und Erweiterungen vorgenommen. Betroffen sind z.B. die Darstellung von Teilabschnitten und Teilkanten sowie die Objekt_ID. |
| 09.10.2020 | Es wurde eine Funktion ergänzt, die für Teilkanten die Geometrie berechnet. |
| 09.10.2020 | Die Ausgabe in einem validierenden XML-Format verlangt, dass mandatorische Elemente stets auszugeben sind. Im Falle von logischen Attributwerten wurde das nicht korrekt beachtet. |
| 24.09.2020 | Bei der Migration von Fachobjekten konnten Fachobjekte aus dem Geometrieschema im falschen Datenbestand landen. Das wurde behoben. |
| 24.09.2020 | Ein neuer Fachbedeutungslistentyp für die Autobahn-GmbH wurde eingeführt. |
| 22.09.2020 | Für die künftig bei der Datenübertragung zu beachtenden Prüfsummen wurden die grundlegenden Voraussetzungen geschaffen. |
| 22.09.2020 | Auf schnellen Systemen kam es zu konkurrierenden Zugriffen auf gemeinsam genutzte Ressourcen bei den Aggregaten, die in der OKLABI benutzt werden. Die Zugriffe werden nun synchronisiert. |
| 02.06.2020 | Veröffentlichung Version 1.3.0.91, Fehlerbereinigung |
| 02.06.2020 | Bei der Erstellung eines Datenbankindex trat ein Fehler auf, wenn eine implizite Geometrie übertragen werden sollte. |
| 07.05.2020 | Durch die händische Bearbeitung von Testdaten enstand ein inkonsistenter Zustand aufgrund einer nur einseitig angegebenen Relation. Beim Einlesen gingen Relationen halbseitig verloren, so dass nur eine der beiden Relationsrichtungen definiert war. |
| 07.05.2020 | Während des Einlesens von XML können temporäre Fachobjekte entstehen (z.B. Koordinatenreferenzsystem). Nach dem erfolgreichen Einlesen können die Fachobjekte verschwinden. Das ist erforderlich, damit nachfolgende Profilprüfungen keine falschen Resultate liefern. |
| 07.05.2020 | Wenn ein Profil viele Definitionen von Objektarten enthält, war ein spürbarer Effekt zu erkennen, wenn Objektarten in einem Schema gesucht wurden, in dem viele Einträge vorkommen (z.B. Schluesseltabellen). Der zugrunde liegende Suchvorgang wurde verbessert. |
| 05.05.2020 | Bei der Datenübertragung in eine Datenbank werden die benötigten Strukturen dynamisch nach Bedarf angelegt. Es kam zu einer Kollision, da ein Indexname benutzt wurde, der bereits als Tabellenname definiert war. |
| 04.05.2020 | Zur Vorbereitung des Einbaus der Unterstützung für SQLite-Datenbanken mit SpatiaLite-Erweiterung wurd eine neue DLL hinzugefügt, um die neue Funktionalität nutzen zu können. Die neue DLL wird für alle unterstützten Konfiguration mit angeboten. |
| 25.04.2020 | Veröffentlichung Version 1.3.0.89 |
| 22.04.2020 | Die Ansteuerung der Ausgabe in die Datenbank wurde erweitert, um den Export eines Datenbestandes passend zu einem Profil zu verbessern. Hier kann man nun wählen, ob man nur die Objektarten gemäß Profil einschränkt, oder ob ausschließlich die im Profil zugelassenen Eigenschaften in den Datenbanktabellen angelegt werden. |
| 21.04.2020 | Man kann im Datenbank-Parameterdialog die in der Datenbank bekannten Schemanamen erfragen. Aufgrund eines Fehlers in der Abfrage an die Datenbank wurden keine Schemanamen gefunden und zur Auswahl angeboten. Bitte beachten: es gibt reservierte Schemanamen in PostgreSQL! |
| 20.04.2020 | Die Verwendung von Schemata in PostgreSQL-Datenbanken ist ein gutes Mittel zur Separation von Datenbeständen innerhalb einer Datenbank. Hierbei müssen Schemanamen sonderbehandelt werden, wenn Großbuchstaben und/oder Sonderzeichen benutzt werden. Bei der Behandlung der Schemanamen traten Fehler in der Anbindung auf, die behoben wurden. Es wird empfohlen, keine Sonderzeichen oder Umlaute zu benutzen, um Probleme mit anderen Werkzeugen (z.B. pgAdmin) zu umgehen. |
| 07.04.2020 | Die OKLABI kann beim Laden von XML-Dateien und aus einer PostgreSQL-Datenbank nun im parallelen Betrieb eingesetzt werden. Per Vorgabe werden soviele Threads beim Befüllen der Daten benutzt wie es Kerne auf dem System gibt. Durch den Konfigurationsparameter AnzahlThreads=-1kann die Nebenläufigkeit unterdrückt werden. Auf sehr schnellen Systemen kann es sinnvoll sein, die Zahl der Threads auf 8 zu begrenzen. |
| 05.04.2020 | Neue Komponenten für die OKLABI: Die Java-Bibliothek zum Laden und Entladen von PostgreSQL-Datenbanken, ein Tutorial mit Erklärungen, Fragen und Antworten zur Benutzung der OKLABI und ein Java-Testprojekt mit Beispielen zur Benutzung der Schnittstelle. |
| 31.03.2020 | Im Bereich der Objektart Erwerbs(teil)fläche war die Migration nicht vollständig angebunden. Hier ist nun die Migration ebenfalls möglich zwischen den Versionen 2.017 und 2.018. |
| 27.03.2020 | Die neue Version 1.3 des Profile-Datenschemas wurde veröffentlicht und an die OKLABI angebunden. |
| 25.02.2020 | Seit der OKSTRA-Version 2.019 gibt es Objektartennamen, die ein Minuszeichen enthalten. Die zugehörigen Tabellennamen müssen sonderbehandelt werden bei der Kommunikation mit der Datenbank. |
| 25.02.2020 | Die Ansteuerung des betreffenden Plug-In wurde geändert, um die Definition eines Datenbankschemas zu einem Profil zu gestatten. Hier kann man nun wählen, ob man nur die Objektarten gemäß Profil einschränkt, oder ob ausschließlich die im Profil zugelassenen Eigenschaften in den Datenbanktabellen angelegt werden. |
| 28.01.2020 | Das Schließen des OKSTRA-Werkzeug wurde beschleunigt, indem unnötige Aktionen wie z.B. die vollständige Löschung des geladenen Datendestands abgestellt wurden. |
| 27.01.2020 | Es wurde die Möglichkeit geschaffen, zusätzliche Informationen bei der Transformation von Koordinaten zu protokollieren. |
| 22.01.2020 | Aufgrund einer Schnittstellenänderung im Bereich der Datenbankanbindung bekamen Datum-Werte einen anderen Datentyp zugewiesen. Das wurde in der Ladeschnittstelle aus Datenbanken berücksichtigt. |
| 18.12.2019 | Bei Verwendung einer ungültigen Fachbedeutungslisten-Version konnte es zu einem Abbruch kommen. |
| 02.12.2019 | Die neuen Möglichkeiten zur Nutzung von mehreren Threads beim Laden von Daten gaben die Veranlassung für neue Konfgurationsparamter. |
| 25.10.2019 | Veröffentlichung Version 1.3.0.86 |
| 30.09.2019 | Zur Verbesserung der Genauigkeit von Koordinatentransformationen wurde die Möglichkeit eingebaut, Gitterdateien zu verwenden beim Einsatz des eingebauten Transformierers (basierend auf dem PROJ-Paket). Es wurden neue Konfigurationsparameter eingebaut zur Kontrolle dieser Möglichkeiten, und es gibt einen Standardordner für solche Dateien, den man in der Benutzerkonfiguration festlegen kann. Die Gitterdateien sind vom Anwender selbst (z.B. bei den Vermessungsverwaltungen der Länder) zu beschaffen. Es wurde ein neuer Dialog unter Einstellungen>Koordinatensystem>Gitterdatei eingebaut, mit dem man die Gitterdateien interaktiv auswählen kann. |
| 23.09.2019 | Bei Linien, die aus Segmenten mit verschiedenem Linientyp bestehen, kam es beim Export in der Version 2.x gelegentlich zu leeren gml:Curve-Elementen. Diese verursachten ein Fehlverhalten beim erneuten Laden der Daten, wodurch die Liniengeometrie verloren ging. |
| 17.09.2019 | Die Anzeige von SVG in verschiedenen Browsern funktioniert nicht richtig, wenn man neuere Versionen von Chrome, Firefox etc. einsetzt. Das liegt daran, dass die sogenannte same origin policy aus Sicht der Browser verletzt ist. Eine Abhilfe aus Sicht des OKSTRA-Werkzeug ist zurzeit nicht bekannt. Es ist jedoch möglich, im Firefox-Browser unter about:config die Einstellung security.fileuri.strict_origin_policyauf false zu setzen. Den Chrome-Browser kann man mit einem Parameter aufrufen: chrome.exe --allow-file-access-from-files. Die Microsoft-Browser sind anscheinend nicht betroffen von diesem Problem. |
| 17.09.2019 | Bei der grafischen Anzeige mit SVG wurde eine temporäre SVG-Datei nicht gelöscht. |
| 17.09.2019 | Verschiedene Aktionen erzeugen eigene Protokolle, z.B. das Lesen oder Prüfen von Daten sowie auch die Übertragung von Daten zur Datenbank und zurück. In diese Protokolle wird nun ein Versionstext ausgegeben, anhand dessen man die benutzte Version der Software erkennen kann. Damit kann die Analyse beim Auftreten von Problemen verbessert werden. |
| 17.09.2019 | Bei der fachlichen Prüfung von geordneten Relationen mit einem Anordnungskriterium konnte es vorkommen, dass bei einem Verstoß die gemeldeten Werte missverständlich ausfielen, weil durch eine zu radikale Rundung keine Unterschiede sichtbar wurden. Weiterhin wurde die Untersuchung beendet, sobald der erste Verstoß gegen die korrekte Anordnung auftrat. Hier wird nun die gesamte Liste bearbeitet, um alle Problemfälle anzuzeigen. |
| 17.09.2019 | Die Bedingung, dass eine Eigenschaft mit anderen Eigenschaften an einem Fachobjekt in einer exklusiv-oderBeziehung steht, wurde nicht richtig ausgewertet für den Fall, dass keines der beteiligten Attribute belegt war. |
| 07.08.2019 | Die in jüngerer Zeit erfolgten Optimierungen beim Lesen von XML-Dateien hatten unter anderem zur Folge, dass sich die Reihenfolge ändert, in der Schlüsseltabellenobjekte gelesen werden. Dadurch kam es beim Lesen von Fachobjekten, die eine Schlüsseltabelle per Kennung benennen, zu einem Fehler, wodurch der Attributwert leer blieb. Es entstand ebenfalls ein leeres Schlüsseltabellenobjekt, das bei dem Transport in eine Datenbank einen Abbruch verursachte. |
| 06.08.2019 | Bei Anwendungen von Koordinatentransformationen konnte es vorkommen, dass Bestandteile von Geometrien falsch behandelt wurden. Dadurch entstand die Situation, dass in einer Geometrie gemischte Koordinatenreferenzsysteme vorkamen, die auch noch falsch bezeichnet waren. Ferner wurden Zwischenpunkte auf Kreisbögen nicht korrekt transformiert. |
| 02.08.2019 | Die Anzeige der Information zu den Fachobjekten bei der grafischen Darstellung wurde vereinheitlicht und erweitert. Zu Fachbedeutungsschlüsseln wird nun der Übersetzungswert mit angezeigt. Einige sehr lange Beschriftungen wurden verkürzt. |
| 29.07.2019 | Veröffentlichung Vorab-Version 1.3.0.84 |
| 18.07.2019 | Wenn ein Eingabedatensatz ein Profil benennt, wird dieses nach Abschluss des Ladens der Daten zur Prüfung der Daten benutzt. Im OKSTRA-Werkzeug kann man diese Prüfung unterbinden, was bei der Benutzung in OKSTRA-Skript jedoch nicht richtig beachtet wurde. Wenn nun das Profil nicht gefunden wurde, war der (möglicherweise langwierige) Ladevorgang vergeblich. Es wird nun zu Beginn des Ladens geprüft, ob das Profil verfügbar ist. Per Vorgabe ist die Profilprüfung beim Laden von Daten deaktiviert. |
| 16.07.2019 | Bei der Übertragung von Daten in eine Datenbank unter Benutzung eines Schemas wurde die Sequenz zur Bestimmung der Objekt-Ids im Schema "public" erzeugt. Das konnte zu einem Abbruch führen. |
| 15.07.2019 | Bei der Benutzung von OKSTRA-Skript in einer Power Shell Umgebung gab es einen Abbruch, wenn die Ausgabe in eine Datei umgelenkt wurde. Diese Situation wird nun erkannt und die Änderung der Fenstergröße (Ursache des Abbruchs) nicht mehr versucht. |
| 04.07.2019 | Bei der Übertragung von Daten in eine Datenbank entstanden Probleme dadurch, dass direct_position ein Datentyp ist und in der Version 2 nicht mehr zum Geometrieschema gehört. |
| 25.06.2019 | Profildateien werden gegen das Profil-Datenschema geprüft, bevor sie benutzt werden können. Da es mehrere Versionen des Profil-Datenschemas gibt, kann es mehrere Prüfungen je Profildatei geben. Dabei treten Meldungen auf, die ignoriert werden können, und es wurde gegebenenfalls versucht, das Profil-Datenschema aus dem Internet zu lesen, obwohl es lokal volhanden ist. Die Vorgehensweise wurde geändert, sodass nur noch zutreffende Meldungen gezeigt werden. Ferner kann dieser Prüfvorgang komplett ohne Internetzugriff auskommen. |
| 24.05.2019 | Daten werden oftmals ohne Angabe eines Koordinatenreferenzsystems angeliefert. Dafür gibt es im OKSTRA-Werkzeug die Möglichkeit, das Koordinatenreferenzsystem zu initialisieren. Hierbei trat in den OKSTRA-Versionen 2.x ein Fehler auf, es wurde versucht, eine Transformation auszuführen, ohne dass ein System vorlag. Die Klasse Transformierer wurde erweitert, um das Koordinatenreferenzsystem initialisieren zu können, ohne eine Transformation auszuführen. Das Verhalten kann durch die Konfiguration gesteuert werden, ob es überhaupt möglich ist, eine Initialisierung auszuführen. |
| 06.05.2019 | Veröffentlichung Version 1.3.0.82 |
| 18.04.2019 | Ein Fehler bei der Migration von Daten zwischen OKSTRA-Versionen führte dazu, dass Fachobjekte der Objektarten Baudienststelle und Verwaltungsbezirk verloren gehen konnten. |
| 22.03.2019 | Manche Ausnahmen beim Lesen von Profildateien wurden nicht abgefangen und gemeldet, wodurch missverständliche Meldungen in der Oberfläche entstanden. Hier wurden neue Meldungen eingebaut, um in einem solchen Fall die Problemsuche zu erleichtern. |
| 19.03.2019 | Bei Dateinamen in der Konfigurationsdatei konnte ein Fehler auftreten, wenn unter Windows ein / statt \ benutzt wurde. |
| 15.03.2019 | Die neu eingeführten Konfigurationsparameter wurden im Einstellungsdialog berücksichtigt. |
| 07.03.2019 | Beim Lesen von XML wurden Verbesserungen vorgenommen. Dadurch wird der Speicherbedarf erheblich gesenkt und die Laufzeit beim Lesen der Metadaten reduziert. Die Laufzeit beim zweiten Lesedurchgang konnte deutlich gesenkt werden durch Vermeidung eines quadratischen Effektes, der insbesondere bei sehr großen XML-Dateien wirksam wurde. |
| 22.02.2019 | Die Methoden zur Transkodierung von Zeichenketten waren unvollständig. Dadurch ging Information verloren. Zur Abhilfe wurde die Transkodierung nun auf die open source Komponente iconv umgestellt. Das frühere Verhalten kann durch den neuen Konfigurationsparameter IconvTranskodierer=neineingestellt werden. Durch die neue Klasse Transkodierer und eine neue Registriere-Schnittstelle an der Klasse Umgebung kann eine Anwendung einen eigenen Transkodierer benutzen. |
| 15.02.2019 | Die Meldungen beim XML-Import und -Export wurden mit Fehlernummern ausgestattet, um eine bessere Erkennung der Situation zu ermöglichen. Es wurden neue Fehlernummern eingeführt, bitte in der Dokumentation (Abschnitt 6.5) nachsehen. |
| 15.02.2019 | Die Migration des Datentyps Jahr nach ASB_Datum und umgekehrt war nicht vollständig implementiert. |
| 15.02.2019 | Die Klasse Protokollant wurde mit Information zur Zeichenkodierung ausgestattet, um doppelte Transkodierungen vermeiden zu können. |
| 14.02.2019 | Durch eine neue Aktion ist es nun möglich, eine Profildatei im OKSTRA-Werkzeug bereit zu stellen. |
| 14.02.2019 | Der Enumerator zur Aufzählung aller Profile funktionierte nicht richtig, wenn eine ungültige Profildatei im Pfad vorkam. Das OKSTRA-Werkzeug und der Profileditor geben nun eine Meldung aus, wenn eine ungültige Profildatei vorgefunden wird. |
| 13.02.2019 | Bei der Generierung von Testdaten muss bei der Behandlung von Relationen auf mehrere Kardinalitäten Rücksicht genommen werden. Hierbei konnte es vorkommen, dass ein falsches Intervall der Anzahl von Relationspartnern bestimmt wurde (untere Grenze größer als obere Grenze). |
| 11.02.2019 | Siehe auch der Eintrag vom 18.01.2019: Die Behandlung von unbegrenzten Intervallen mit eingeschlossener Grenze war unvollständig und wurde erweitert. Ein betroffenes Profil sollte einmal im Profileditor geöffnet und wieder exportiert werden. |
| 08.02.2019 | Es wurde bei der Objektart PCV die Situation entdeckt, dass diese seit der Version 2.015 ein komplexer Datentyp ist, jedoch weiterhin wie früher von OKSTRA_Objekt erbt. Dadurch entsteht ein falsches XML-Format. Dieser Fehler wurde in der Schemadatenbank behoben. Im Datenmodell wird der Fehler in Version 2.019 behoben. |
| 08.02.2019 | Beim Laden von XML-Daten, in denen die Objektart Punktvermarkung vorkommt, fehlte eine Versionsweiche für frühere OKSTRA-Versionen. Dadurch wurde versucht, eine nicht mehr vorhandene Relation zu setzen. |
| 07.02.2019 | Die Datenbankschnittstelle wurde für Multischemabetrieb eingerichtet. Siehe die Dokumentation beim OKSTRA-Werkzeug. |
| 28.01.2019 | Die OKLABI besitzt zur Zeit keine vollständige Unterstützung für die Transkodierung zwischen den beim Datenaustausch benutzten Zeichensätzen (ISO-8859-1, UTF-8). Hier wurde vor kurzem der Zeichensatz Windows-1252 eingeführt. Beim Transport in ISO-8859-1 und UTF-8 kam es aufgrund von Sonderzeichen zu Problemen. Es wird empfohlen, unter Windows mit der Kodierung Windows-1252 zu arbeiten bis ein vollwertiger Transkodierer in die Schnittstellen integriert ist. |
| 18.01.2019 | Wenn in einem Profil bei einer numerischen Eigenschaft ein unbegrenztes Intervall angegeben war, dessen Grenze mit enthalten sein sollte, kam es bei der Anwendung dieses Profils zu Fehlern. Bei offenen Intervallen wird nun beim Export eines Profils dafür gesorgt, dass die Intervallgrenze ausgeschlossen ist. |
| 14.12.2018 | Neu im Datenmodell erscheinen nun auch Bedingungen an Eigenschaften. Der Transport dieser Information aus dem UML-Datenmodell in die Schemadatenbank war fehlerhaft. |
| 03.12.2018 | Eine Qualitätssicherung am Quellcode der OKLABI unter Einsatz eines neuen Compilers (Clang 7) lieferte diverse Hinweise auf Verbesserungsmöglichkeiten. |
| 30.11.2018 | Wenn bei Verwendung des Kompatibilitätsmodus für Geometrie ein Koordinatenreferenzsystem aufzusetzen war, wurde die Umstellung bei der entsprechenden Schlüsseltabelle zwischen Version 2.016 und 2.017 nicht richtig behandelt, es kam zu einer Ausnahme. |
| 29.11.2018 | Im Kompatibilitätsmodus für Geometrie wurde beim Export von Linien nach XML (als Curve) keine gml:id erzeugt. Dieser Fall trat auf, wenn in der Linie Segmente mit verschiedenem Linientyp vorkamen (z.B. Gerade und Kreisbogen). Hierbei wurden fälschlich innerhalb der Linie neue curveMember-Elemente erzeugt. In Version 2.x muss das Curve-Element zudem stets eine gml:id erhalten. |
| 23.11.2018 | Die Migration der Schlüsseltabelle Koordinatenreferenzsystem von Version 2.016 nach 2.017 war fehlerhaft. Hier erfolgt ein Wechsel von einer Schlüsseltabelle zu einem Datentyp, der nicht richtig abgebildet wurde. |
| 22.11.2018 | In einer Schlüsseltabelle (Teilnetzklasse) der Version 2.018 wurden doppelte Schlüsseleinträge definiert. Die Schemadatenbank wurde berichtigt. |
| 21.11.2018 | Bei der Anlage der Datenbanktabellen zur Version 2.018 kam es zu einem Abbruch, weil der Attributname Offsetin der SQL-Sprachumgebung eine eigene Bedeutung besitzt. |
| 21.11.2018 | Der neu als Konfigurationsparameter eingeführte Faktor für den Datenbank-Timeout wurde im Eigenschaftsdialog mit angebunden. |
| 20.11.2018 | Für den Datenaustausch im XML-Format muss eine Kodierung angegeben werden. Traditionell ist das ISO-8859-1. Es gibt mindestens zwei Zeichen im OKSTRA-Datenmodell, die darin nicht unterstützt werden: € und ‰. Der Zeichensatz ISO-8859-15 kennt zwar das €-Symbol, jedoch nicht das ‰-Zeichen. Im Format UTF-8 lassen sich diese Zeichen sämtlich problemlos transportieren. Es wurde nun die Möglichkeit zur Auswahl des Windows-1252 Zeichensatzes ergänzt, weil dieser ebenfalls alle gebräuchlichen Zeichen unterstützt und auf Windows-Plattformen der Standardfall ist. |
| 20.11.2018 | Wenn eine Anwendung einen eigenen Ressourcenpfad setzte, der mit einem Punkt beginnt (relative Angabe), scheiterte die XML-Schemavalidierung gegen den lokalen Pfad, auch wenn die Schemadefinition am richtigen Ort lag. Beim Setzen eines relativen Ressourcenverzeichnisses wird nun das aktuelle Verzeichnis in den Pfad hinein substituiert. |
| 16.11.2018 | Veröffentlichung Version 1.3.0.73 |
| 09.11.2018 | Beim Laden von Daten in der OKSTRA-Version 2.x unter Benutzung des Kompatibilitätsmodus für Geometrie wurde das Koordinatenreferenzsystem falsch übertragen, es kam zur Verwendung einer in OKSTRA-Version 2.x nicht unterstützten Schlüsseltabelle. |
| 19.10.2018 | Beim Abzug von Daten aus einer SQL-Datenbank in das OKSTRA-Format kam es zu einem Datenbank-Timeout. Hierfür wurde ein neuer Konfigurationsparameter eingebaut (Vorgabe: TimeoutFaktor=50). Durch Veränderung dieses Faktors kann man nun den Timeout über die Konfiguration steuern. |
| 02.10.2018 | Veröffentlichung Version 1.3.0.71 |
| 28.09.2018 | Zur besseren Erkennung, welcher Schritt beim Laden von XML-Daten wieviel Zeit verbraucht, wurden mehrere Meldungen im XMLEingabeKonverter ergänzt, die Zeitstempel ausgeben. Dadurch ändert sich geringfügig das Aussehen von Ladeprotokollen |
| 28.09.2018 | Bei der Antwort eines Web-Feature-Service (WFS) wird nun zusätzlich zum wfs:ServiceExceptionReport nun auch ein ows:ExceptionReport erkannt |
| 28.09.2018 | Der Dialog zur Anbindung eines WFS im OKSTRA-Werkzeug wurde etwas flexibler gestaltet und weiter ausgebaut. Aufgrund technischer Einschränkungen kann zur Zeit das https-Protokoll nicht verwendet werden, darauf wird im Dialog hingewiesen |
| 18.09.2018 | Zur Erleichterung der Fehlerbehandlung wurden allen Meldungen aus dem Umfeld der fachlichen Prüfung und etlichen weiteren vordefinierten Fehlermeldungen eine eindeutige Meldungsnummer zugeordnet. In der Dokumentation wird in einem neuen Abschnitt im Anhang die Liste aller bekannten Meldungsnummern und -inhalte aufgeführt. Die Beispiele im Handbuch zur Demonstration der Programmierung von Protokollanten wurden erweitert |
| 14.09.2018 | Bei der Generierung von Testdaten zu einem Profil, in dem eine maximale Objektanzahl zu einer Objektart festgelegt ist, konnte es zu einer Verletzung dieser Bedingung kommen. Das geschah zumeist während der Bearbeitung einer inversen Relation im Verlauf der Datengenerierung |
| 23.08.2018 | Verschiedene fachliche Prüfungen, die Bedingungen zwischen mehreren Eigenschaften und die Anordnung von Listenrelationen auswerten, wurden nachgerüstet. Hierfür wurde auch das Format der Schemadatenbank erweitert. Diese Bedingungen sind aus den früher in EXPRESS definierten WHERE-Bedingungen entnommen worden |
| 23.08.2018 | Der Haupt-Dialog wurde umbenannt. Der Name eines gewählten Profils war nicht lesbar, wenn dieser sehr lang war |
| 06.08.2018 | Rekursiv definierte Datentypen (z.B. Zeitraum) führten zu fehlerhaften Daten bei der Generierung von Testdaten. Die Rekursion wird nun bei der Generierung aufgebrochen. Außerdem wurde die Prüfung von Relationen erweitert, um verbotene inverse Relationen zu erkennen |
| 06.08.2018 | Der Objektnavigator im OKSTRA-Werkzeug erlaubt es, Fachobjekte zu löschen. Dabei wurden nicht alle Verweise auf das gelöschte Fachobjekt in der Baumdarstellung beseitigt, wodurch es zu einem Abbruch kommen konnte |
| 24.07.2018 | Während des Einlesens von XML-Daten konnte es in seltenen Fällen zu einem Abbruch kommen (Speicherschutzverletzung) aufgrund eines technischen Problems in der Behandlung von Ausnahmen |
| 23.07.2018 | Die Prüfung eines Vereinigungs-Datentyps (union) mit einem Profil lieferte falsche Meldungen zu Kardinalitäten. Bei einer union darf nur genau eine Eigenschaft des komplexen Typs belegt sein |
| 20.07.2018 | Beim Laden von XML-Daten, in denen eine Strassenbezeichnung vorkommt, konnte es zur Benutzung eines falschen Rollennamens kommen. Dadurch war die Strasenbezeichnung nach dem Laden nicht verfügbar. Der Grund für diese Situation lag in einer Sonderbehandlung, die aus sehr frühen Version des OKSTRA-XML Formates stammt |
| 14.06.2018 | Veröffentlichung Version 1.3.0.68 |
| 01.06.2018 | In manchen Versionen vor 1.012 gab es Fehler im Datenschema, wodurch bei symbolischen Objekten inverse Relationen nicht gefunden wurden. Diese Fälle müssen sonderbehandelt werden. Im Testdatengenerator war eine Anpassung erforderlich, um einen hierdurch ausgelösten Abbruch zu vermeiden |
| 01.06.2018 | Schlüsseltabellen und Datentypen, die eine Eigenschaft besitzen mit dem Namen einer Objektart, müssen beim Lesen sonderbehandelt werden, um Fehlinterpretationen des XML-Formates zu vermeiden. Hierbei konnte es zu einer Namenskollision kommen, wodurch ein Abbruchfehler verursacht wurde |
| 01.06.2018 | Die Objektart Zeitraumwurde falsch migriert beim Übergang von Version 1.011 nach 1.012 |
| 18.05.2018 | Das Promillezeichen ist im Zeichensatz ISO-8859-1 nicht darstellbar, es wird nach dem Einlesen aus einer XML-Datei als Fragezeichen dargestellt. Als Abhilfe soll in Zukunft die XML-Ausgabe per Standard im Format UTF-8 erfolgen |
| 17.05.2018 | Bei der Migration von Multi-Geometrie gingen Komponenten verloren |
| 14.05.2018 | Veröffentlichung Version 1.3.0.67 |
| 09.05.2018 | Ein Fehler im Datenschema (bei Relationen der Objektart Dokument in das Schema S_Pruefdaten) wurde entdeckt. Daher ist ein Update des OKSTRA-Datenschemas und der Komponenten der OKSTRA-Klassenbibliothek erforderlich |
| 27.04.2018 | Veröffentlichung Version 1.3.0.66 |
| 23.04.2018 | Die Herstellung einer Textdarstellung für Profile wurde verfügbar gemacht (neues Plugin). Für die Benutzung muss zuvor ein Profil ausgewählt werden |
| 18.04.2018 | Bei der Ausgabe von XML-Dateien in der Kodierung UTF-8 entstanden ungültig kodierte Dateien. Es konnte zusätzlich eine doppelte Wandlung nach UTF-8 vorkommen, was nun verhindert wird. Es wurde eine neue Methode an DateiAusgabe ergänzt, mit der die Kodierung erfragt werden kann |
| 12.03.2018 | Die Migration von Multigeometrie wurde nicht immer korrekt durchgeführt |
| 12.03.2018 | Die Datenprüfung konnte scheitern, wenn eine ungültig benannte Fachbedeutungsliste in den Daten vorkam |
| 20.02.2018 | Beim Einlesen von XML-Daten in der UTF-8 Kodierung traten Fehler auf |
| 13.02.2018 | Bei der Überprüfung auf den Typ Ausnahme konnte unter bestimmten Umständen Speicherschutzverletzungen auftreten |
| 31.01.2018 | In Schnittstellen-Wrappern wurden Objekte des Typs Ausnahme nicht richtig erkannt, wodurch Informationen im Fehlerfall verloren gehen konnten |
| 30.01.2018 | Beim Lesen von Gleitkommazahlen unter Linux gingen aufgrund der Lokalisierung Nachkommastellen verloren |
| 26.01.2018 | Die Unterstützung für das Euro-Zeichen wurde verbessert |
| 11.01.2018 | Multiple Liniengeometrie falsch eingelesen in Version 2.017 |
| 10.01.2018 | Beim Zugriff auf die Geometrie von Achselementen traten unnötige Meldungen auf |
| 05.01.2018 | Die unbeaufsichtigte Installation wartete auf Nutzereingaben in einem Dialog |
| 25.09.2017 | Beim Abzug von OKSTRA-Daten aus einer Datenbank konnte es vorkommen, dass Listenrelationen falsch dargestellt wurden |
| 07.09.2017 | Die Darstellung von deaktivierten Schlüsseltabellenwerten unter einer Eigenschaft in einem Profil war falsch. Die Prüfung gegen das Profil lieferte nicht das korrekte Ergebnis. |
| 05.09.2017 | Bei falsch aufgebauten Geometrien wurde der Datenbestand unvollständig aufgeräumt nach dem Laden |
| 06.09.2017 | An- bzw. Abwahl von Schlüsseltabellenwerten unter einer Eigenschaft konnte zu einem Abbruch führen |
| 05.09.2017 | Profil-Version 1.2 veröffentlicht |
| 17.08.2017 | Nicht ASB-konforme Netzknotennummern (mehr als 3 Stellen) bewirkten, dass Verweise per Fachkennung nicht aufgelöst werden konnten. Die Erkennung dieser Situation wurde verbessert, damit nach dem Laden von Daten die referierten Fachobjekte dennoch gefunden werden. Dieser Fall tritt z.B. in OKSTRA-Daten aus Hamburg auf. |
| 17.07.2017 | Neue Funktionalität bei Eigenschaften und Profilen, um Eigenschaftswerte einschränken zu können. |
| 14.07.2017 | Geänderte Schnittstelle bei Profilen |
| 13.06.2017 | Ein Fehler bei der Freigabe von Profilen, die noch in Benutzung sind, wurde behoben |
| 09.07.2017 | Ein neues Plugin wurde erstellt, mit dem man Datenbestände derselben Version zusammenführen kann |
| 08.06.2017 | In älteren OKSTRA-Versionen sind manche inverse Relationen noch nicht definiert. Hier müssen künstliche Relationen benutzt werden |
| 08.06.2017 | Die Meldungen bei ungültigen Stationen von Straßenpunkten und Teilabschnitten wurden verbessert |
| 07.06.2017 | Die Zusammenfassung von Liniensegmenten führte zu einem Abbruch, weil verschiedene Genauigkeitsmaße benutzt wurden |
| 07.06.2017 | Im Objektnavigator wird die doppelte Ausgabe derselben Geometrie nun verhindert |
| 06.06.2017 | Migration zwischen Versionen korrigiert und erweitert (Bereich Baudienststelle und Verwaltungsbezirk) |
| 06.06.2017 | Wenn ein Profil in einem Datensatz genannt wird, dass von der Oklabi beim Laden nicht gefunden wird, kam es zu einem Abbruch, der einen unvollständig bearbeiteten Datenbestand zurücklässt |
| 31.05.2017 | Ein Korrekturmodus wurde eingeführt, um falsch abgebildete Geometrie an Abschnitten und Ästen zu bereinigen |
| 26.05.2017 | Behandlung von Spaltennamen an PostgreSQL-Bedürfnisse anpassen |
| 26.05.2017 | Stationskorrektur in OKSTRA-Skript eingebaut |
| 23.05.2017 | Mehrere parallele Läufe des OKSTRA-Werkzeug erlauben |
| 15.05.2017 | Anzeige der Versionsnummer korrigiert |
| 15.05.2017 | Minimale Objekt-Kardinalität bei Prüfung gegen ein Profil nicht korrekt geprüft |
| 27.04.2017 | Multiple Flächengeometrie falsch exportiert |
| 27.03.2017 | Veröffentlichung Version 1.3.0.55 |
| 23.03.2017 | Fehler beim Laden einer Datei führen nun im Skript-Werkzeug zum Abbruch der Verarbeitung |
| 23.03.2017 | Eine Fläche mit einer aus mehreren Segmenten zusammengesetzten Randlinie wurde nicht exportiert |
| 21.03.2017 | Bei der Migration mit aktivem Express-Kompatibilitätsmodus in der Version 2 ging Geometrie verloren |
| 21.03.2017 | Das Laden von Daten, zu denen ein Profil angegeben ist, scheiterte wenn das Profil nicht gefunden wurde. Die zugehörige Meldung wurde verschluckt. Es wurde ein Warnhinweis ergänzt, der nach Abschluss des Ladens erscheint. |
| 20.03.2017 | Der XML-Namespace wurde bei IDMVU-Daten falsch behandelt |
| 16.03.2017 | Meldung bei Fehlern während der Schemavalidierung einer XML-Datei eingeführt |
| 15.03.2017 | Während der Migration von Daten aus Version 1.x nach ging Geometrie verloren |
| 14.03.2017 | Beim Import aus dem WKT-Format wurden die Segmente von Liniengeometrien nicht verbunden |
| 14.03.2017 | Beim XML-Export in der Version 2.x wurden teilweise Flächengeometrien nicht ausgegeben, wenn diese aus einer einzigen Komponente bestanden |
| 13.03.2017 | Fehlerhafte Meldungen bei der Prüfung von Fachobjekten vemeiden |
| 09.03.2017 | Ab der OKSTRA-Version 2.016 müssen Relationen in einer Datenbank in beiden Richtungen eingetragen werden |
| 09.03.2017 | Die Fortschrittsanzeige blieb im Batch-Betrieb wirklungslos |
| 28.02.2017 | XML-Sonderzeichen in den Metadaten verursachten XML-Formatfehler |
| 28.02.2017 | Die Behandlung von Profilen wurde korrigiert |
| 06.02.2017 | Eine im WKT-Format angelieferte Multigeometrie wurde nicht an den Komponentengrenzen aufgetrennt |
| 06.02.2017 | Es wurde versucht, ein POLYGON in WKT-Darstellung als MULTIPOLYGON zu lesen, das Ergenis war leer. |
| 02.02.2017 | Beim Anhängen von Punkten an eine Linie wurden neue Komponenten gebildet anstatt den Linienzug fortzusetzen, wenn die Linie mehr als eine Komponente enthielt. |
| 02.02.2017 | Eine Linienunterbrechung ist bei XML-Ausgabe nicht transportabel. Es wird nun eine neue Geometriekomponente begonnen, wenn Unterbrechung auf true gesetzt wird. |
| 26.01.2017 | Warnung vor leerem Stringattribut in Schlüsseltabelle unterdrückt |
| 24.01.2017 | Programmabbruch (Stack Overflow) aufgrund von rekursiv definierten Geometrien verhindern |
| 19.01.2017 | Prüfung von Relationen auf Schema-Konformität verbessert |
| 18.01.2017 | Verbesserung der Meldungsausgabe im Falle von Abbruch der Anwendung |
| 18.01.2017 | Namespace-Behandlung überarbeitet (Default-Namespace, okstra-typen) |
| 11.01.2017 | Ressourcen-Pfad wurde beim Lesen der Benutzerkonfiguration zurückgesetzt |
| 20.12.2016 | Veröffentlichung Version 1.3.0.45 |
| 15.12.2016 | Abbruch aufgrund falscher Befüllung von Daten musste verhindert werden, es wird nun eine Meldung ausgegeben |
| 06.12.2016 | Fehler in DBImporteur behoben (fehlende Fachobjekte beim Export) |
| 01.12.2016 | Fehler bei komprimiertem Schreiben unter 64 Bit behoben |
| 01.12.2016 | Zwischentabelle erhielt neue Indizes |
| 29.11.2016 | Multiple Schlüsseltabellen führten zu Abbruch, Multiple Stringattribute: Offset-Fehler behoben |
| 29.11.2016 | Die Metadatentabelle wurde doppelt erzeugt, dadurch Abbruch |
| 29.11.2016 | Abbruch bei Dateiauswahl führt zu Crash |
| 23.11.2016 | Falscher Eigenschaftsname (entlang_Teilabschnitt) für Geometriebeschaffung (richtig: entlang_Routenkomponente) |
| 23.11.2016 | Höhensysteme kamen erst mit Version 2.017 im OKSTRA an, werden aber auch schon in Version 2.016 akzeptiert |
| 17.11.2016 | Datenbankparameter aus Auswahldialog wurden nicht vollständig transportiert |
| 28.10.2016 | Speicherlöcher geschlossen |
| 27.10.2016 | Erfragen von Geometrie aus einem AnyType wurde nicht nach den ausmodellierten Type unterschieden |
| 20.10.2016 | Geometrie: BoundingBox Fehler bei Input (0,0) |
| 13.10.2016 | Geometrieschema-Ausschluss am Datenbanklader zugreifbar gemacht |
| 13.10.2016 | Methode Vereinige am Datenbestand behandelte Objektreferenzen falsch |
| 12.10.2016 | Im/Export per Fachkennung klappte nicht in OKSTRA-Versionen 2.x. Anstelle der Angabe der Fachkennung wurde ein Verweis per xlink:href ausgegeben. Die Fachkennung kann nun auch über die Schnittstelle gesetzt werden, um Objekte per Fachkennung referenzieren zu können. |
| 07.10.2016 | Prüfung von Relationen beim DB-Laden war falsch |
| 04.10.2016 | Längsschnitte in Grafik bei 1.015 fehlten, Fehler bei BoundingBox-Bestimmung |
| 29.09.2016 | Querprofile fehlten in Darstellung |
| 26.09.2016 | Xml namespace hat neue Struktur ab Version 2.017; der Ort der XSD-Datei wurde falsch ermittelt |
| 19.09.2016 | Einige Ausnahmen beim Lesen und Prüfen eines Profils waren nicht erforderlich und konnten durch passende Behandlung erübrigt werden. Beim Schreiben von einzelnen Objektartelementen bei Relationen kamen ungültige Kardinalitäten im Export an. |
| 16.09.2016 | Möglichkeit ergänzt, eine Profildatei außerhalb des Profilpfades zu öffnen. Diese Profile werden am Ende des Profilpfades angehängt bei der Suche nach einem Profil per Namen. |
| 15.09.2016 | XML-Darstellungsfehler beim TYPE Tag. Beobachtbar z.B. in ASB_Datum. Bis Version 1.015 war der Typ Tag im XML-Format auf den type gDay gemapped. Ab Version 2.x ist das ein Integer. Diese Versionsabhängigkeit wurde nicht beachtet. |
| 14.09.2016 | Fehlerbereinigung im Umfeld der Geometrieermittlung von Teilabschnitten und Strassenpunkten bei großen Datensätzen. Meldungen ergänzt, um den Bearbeitungsstand besser zu dokumentieren und um fehlerhafte Stationen anzuzeigen. |
| 13.09.2016 | Volumengeometrien wurden nicht gewandelt beim Im/Export im XML-Format. Im Geometrie-Interface gab es Probleme beim Aufzählen der Inhalte von Volumen im Iterator sowie bei der Zählung der Punkte. |
| 08.09.2016 | Neue Dokumentation für Plugin-Programmierung |
| 17.08.2016 | Neue Version des Datenschemas für Profile eingeführt (Version 1.1) |
| 17.08.2016 | Der OKSTRA-Profileditor wurde als eigenständige Anwendung herausgelöst. Mehr zum Profileditor. |
| 15.08.2016 | Neue Flagge ergänzt, die anzeigt, ob mehr als ein Datenbestand im Plugin benutzt wird |
| 10.08.2016 | Verbesserte Meldungen für den Benutzer, z.B. zum Laden von Fachbedeutungslisten |
| 28.07.2016 | Bei freien Schlüsseltabellen muss auch beim Deaktivieren im Profil auf die Werte zugegriffen werden können |
| 26.07.2016 | Unterscheidung zwischen Modus Profil-Editor und Dateneditor war fehlerhaft, teilweise war kein Editieren möglich |
| 25.07.2016 | OKSTRA-Spezialversionen mit Release-Nummer > 0 erhielten einen falschen XML-namespace zugewiesen und waren daher nicht mehr valide. Betroffene Versionen: 1.008, 1.009, 1.010 und die zugehörigen Korrekturen |
| 22.07.2016 | Neue Schnittstelle ObjektWandler eingebaut für Wandlung von Objekten von Entwurf nach Bestand |
| 20.07.2016 | Höhensysteme nicht erkannt, Namen teilweise falsch |
| 20.07.2016 | Neuer Konfigurationsparameter: Schemafehler nicht erlaubt, Ausnahme werfen |
| 20.07.2016 | Ausgabe ergänzt, uom fehlte bei defaultierten Werten |
| 19.07.2016 | Ausgabe der Statistik in XMLEingabeKonverter korrigiert |
| 19.07.2016 | Suche korrigiert; boundedBy, Envelope nicht gefunden |
| 21.06.2016 | Veröffentlichung Version 1.3.0.36 |
Zurück zur Übersichts- und Downloadseite des OKSTRA-Werkzeugs.
|
|