{"id":20400328,"url":"https://github.com/fschutt/tnviewer","last_synced_at":"2025-03-05T01:28:58.125Z","repository":{"id":247371035,"uuid":"823493210","full_name":"fschutt/tnviewer","owner":"fschutt","description":"Viewer-Tool für die Überprüfung der Tatsächliche Nutzung von Landflächen","archived":false,"fork":false,"pushed_at":"2025-01-02T11:11:04.000Z","size":2224811,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-02-24T21:11:38.840Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://tnviewer.de/","language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/fschutt.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"licenses.html","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-07-03T06:25:14.000Z","updated_at":"2025-02-14T15:32:22.000Z","dependencies_parsed_at":"2024-08-26T10:52:35.464Z","dependency_job_id":"c72eddef-ab19-4fb0-bfa4-123703997c7a","html_url":"https://github.com/fschutt/tnviewer","commit_stats":null,"previous_names":["fschutt/tnviewer","fschutt/tnviewer3"],"tags_count":4,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fschutt%2Ftnviewer","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fschutt%2Ftnviewer/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fschutt%2Ftnviewer/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fschutt%2Ftnviewer/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/fschutt","download_url":"https://codeload.github.com/fschutt/tnviewer/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":241948085,"owners_count":20047325,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-15T04:39:34.683Z","updated_at":"2025-03-05T01:28:58.101Z","avatar_url":"https://github.com/fschutt.png","language":"HTML","funding_links":[],"categories":[],"sub_categories":[],"readme":"# TNViewer\n\n[tnviewer.de](https://tnviewer.de) ist ein Tool zur einfacheren Überprüfung der \nTatsächlichen Nutzung von Landflächen in Brandenburg (und anderen Bundesländern).\n\n\u003cimg width=\"1470\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6b38d815-bed4-424e-aabb-94ebad9426a8\" /\u003e\n\n## Technische Dokumentation\n\n### Problemsituation und Arbeitsablauf\n\nBeim Bearbeiten der tatsächlichen Nutzung in ALKIS treten öfter verschiedene Probleme auf, die\ntechnisch durch das Programm „TNViewer“ gelöst werden könnten. Um die Probleme zu verstehen,\nmuss man zunächst den jetzigen Arbeitsablauf kennen:\n\nBeim Bearbeiten eines Projekts (z.B. einer Gemarkung oder Flur) werden zunächst CSV-Daten aus dem\nLiegenschaftskataster (LiKa online) und ALKIS-Daten im NAS-XML-Format aus dem GeoBroker\nBrandenburg heruntergeladen. Danach werden die Flurstücke (mittels Excel und GeoGraf) gesichtet,\ninwiefern sich die tatsächliche Nutzung verändert. Diese Änderungen werden in einer Excel-Liste\neingetragen, ebenso werden Zeilen markiert, bei denen sich voraussichtlich die Wirtschaftsart ändert.\nDanach wird der Vermessungsriss in GeoGraf gezeichnet, d.h. es werden Linien und Texte in GeoGraf\nals Grafikobjekte (nicht als Flächen) einzeichnet. Nach der Überprüfung des Risses auf Richtigkeit\nwerden die Änderungen in DAVID geändert. Nach der Übernahme in die DHK werden die Produkte\n(Änderungsmitteilungen) geprüft, hierbei ist wichtig, ob ein Flurstück eine veränderte Wirtschaftsart\nhat (da nur Flurstücke relevant sind, wo sich auch die Wirtschaftsart ändert).\nHierbei kommt es zu verschiedenen Fehlerquellen und aufwendigen Prozessen, die umso schlimmer\nwerden, je größer das Projekt (Flur oder Gemarkung) ist:\n\n1. Es ist sehr einfach, im Riss ein Flurstück zu verändern, aber es in der Excel-Liste [P1] nicht einzutragen.\n2. Man muss als Bearbeiter im Voraus wissen, an welchen Flurstücken die Wirtschaftsart geändert\nwird. Bedeutet, man muss (auf Papier / im PDF) bei jeder Änderung nachgucken, welcher\nWirtschaftsart diese Änderung zugeordnet ist und ob es diese Wirtschaftsart bereits an\nirgendeiner Teilfläche gibt.\n3. Wenn man bei dieser Klassifizierung einen Fehler macht, ist das Deckblatt für den\nVermessungsantrag falsch, was nervig ist, weil dort die Unterschriften des Amtsleiters, etc.\neingetragen sind, aber den Beleg, ob man richtig gearbeitet hat, bekommt man erst am Ende\ndes Projekts.\n4. Für jeden Riss muss der Blattkopf die abgebildeten Flurnummern anzeigen und die Legende\nmuss nur die Kürzel anzeigen, welche im Riss auch zu sehen sind.\n5. Grafische Rissobjekte wie „siehe Anschlussriss 4 / 10“ müssen per Hand erstellt werden.\n6. Sollte es bei der Bearbeitung in DAVID irgendein technisches Problem geben (z.B. ein Projekt\nwurde nicht gesperrt, technische Probleme bei der Fortführung) gibt es keinen Weg, die\nÄnderungen separat von den ALKIS-Daten zu speichern: wenn die Objekt-IDs nicht mehr\nstimmen, muss man die Bearbeitung in DAVID wiederholen.\n7. Es kann sehr leicht zu Unterschieden zwischen Excel-Liste / Vermessungsriss und DAVID-\nBearbeitung kommen. Jede Änderung wird mindestens zweimal digitalisiert (in DAVID und in\nGeoGraf). Derzeit ist die einzige Kontrolle ein anderer Mitarbeiter (Vier-Augen-Prinzip), was\nZeit kostet.\n8. Bearbeitete Flurstücke müssen nach Eigentümer gruppiert werden (für ein Formular, das später\nin der Arbeitsmappe landet). Derzeit wird das von Hand in Excel mit Kopieren / Einfügen\nerledigt.\n\nDas Programm „TNViewer“ ist eine HTML-Anwendung (technische Details siehe Abschnitt 2), welches\ndiesen Problemen zuvorkommen soll: Je früher ein Fehler gefunden wird, desto weniger Zeit und\nGehirn kostet es später, diesen zu korrigieren.\n\n### Arbeitsablauf\n\nIm Programm kann man (über „Projekt aus CSV“ und „NAS-Daten importieren“) die CSV-Daten aus\nLiKA online und die NAS-Daten aus dem GeoBroker importieren:\n\n\n\nAuf der linken Seite sieht man die Flurstücke, zu denen man in der Karte per Doppelklick navigieren\nkann. Danach kann man (über „Nutzung einzeichnen“) neue Nutzungen digitalisieren oder existieren\nNutzungen direkt über die Flurstücksliste ändern:\n\n\u003cimg width=\"837\" alt=\"image\" src=\"https://github.com/user-attachments/assets/7986904f-eb3e-434b-b746-5bcb2286209a\" /\u003e\n\n\u003cimg width=\"463\" alt=\"image\" src=\"https://github.com/user-attachments/assets/63015bfe-bf0e-49c8-99f6-8fb6378580e6\" /\u003e\n\nDie Nutzungsarten-Kürzel entstammen aus dem hinterlegten Nutzungsartenkatalog (momentan GID 7.1). \nEbenso kann man oben rechts die Suche benutzen, falls man sich bei der Klassifizierung\neiner Fläche nicht sicher ist (in der jetzigen Bearbeitungsweise muss man das PDF / Papier zu\nHand nehmen).\n\n\u003cimg width=\"620\" alt=\"image\" src=\"https://github.com/user-attachments/assets/1d4cd1aa-f28c-49be-aff2-a6e9447ff12d\" /\u003e\n\nIst die Digitalisierung abgeschlossen, müssen die Flächen noch bereinigt werden (Änderungen säubern\n1 – 6), damit die Punkte 100% auf den Flurstücksgrenzen sitzen und nicht etwa sich leicht\nüberschneiden. Diese Säuberung ist in verschiedene Schritte unterteilt, damit es bei Fehlern einfacher\nist, diese einzugrenzen. Wenn die Säuberung erfolgreich abgeschlossen ist, kann man die\ndigitalisierten Flächen ausgeben: Einmal nach GeoGraf („Export GEOgraf“) sowie nach DAVID („Export\nDAVID“). Hierfür müssen Rissgebiete (blau) über die Änderungen (grün) gelegt werden, damit schnell\ngeplant werden kann, wie viele Risse man für die Arbeitsmappe benötigt.\n\nBeim Export nach GEOgraf erhält man einen ZIP-Ordner mit den Elementen, die jeder Riss benötigt:\nBlattkopf, Legende (berechnet je nach sichtbaren Kürzeln) und Anschlussrisse, sowie die\nbürokratischen Dokumente: Antragbegleitblatt, Fortführungsbeleg und Bearbeitungsliste (generierte\nExcel-Liste, welche Flurstücke bearbeitet wurden):\n\n\u003cimg width=\"1059\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b0e391a3-d0c3-4899-96ee-42d26df5fa53\" /\u003e\n\nEbenso erhält man eine berechnete Excel-Liste, welche Flurstücke wie geändert wurden und - da die\nWirtschaftsarten programmtechnisch für jedes Kürzel hinterlegt sind - ebenso den Beleg, ob ein\nFlurstück veränderte Wirtschaftsarten hat:\n\n![image](https://github.com/user-attachments/assets/54ed4c11-854f-4140-959f-386c426a8eac)\n\nZusätzlich enthält jeder Riss-Ordner eine Vorschau, damit man Probleme schnell erkennt und nicht erst\ndie Linien und Texte in GEOgraf importieren muss, um Platzierungsprobleme zu sehen. Hierbei ist zu\nbemerken, dass die roten Linien zwar als Flächen in der Software gespeichert werden, aber als\nLinienobjekte exportiert werden, wenn sie eine Flurstücksgrenze überschneiden. Das ist wichtig zur\nÜberprüfung, ob die Änderungen sauber auf den Linien liegen.\n\nDanach ist es sehr leicht, die Texte und Linien in GEOgraf zu importieren: Man muss nur über „Import -\nGeoGraf“ die „Projekt.GRAFBAT.out“ Datei (siehe Abbildung Seite 3) in GeoGraf laden, damit werden\ndie Texte, Linie und Punkte automatisch in GeoGraf übernommen. Ebenso hat jeder Riss eine eigene\n„Menge“, damit man Änderungen nicht doppelt in verschiedenen Rissen darstellt und die Elemente\neines Risses unabhängig von anderen Änderungen bearbeiten kann.\n\nNach dem Import und leichter Korrektur der Textpositionen nach GeoGraf sieht dann der Riss ca. so aus:\n\nMan beachte, dass die meisten Texte nicht mehr von Hand bearbeitet werden müssen, die\nTextposition, Platzierung und Bezugspfeile werden vollautmatisch gesetzt!\n\nDa die Textplatzierung automatisch geschieht, sind ebenso alle notwendigen Flächen richtig\nbeschriftet. Alles, was zum manuellen Aufbereiten der Risse noch notwendig ist, ist die Elemente wie\nBlattkopf, Legende und Anschlussrisse zu platzieren und über GeoGraf das PDF zu generieren.\n\nDie importierten Objekte (Texte und Linien) stellen somit sicher, dass jede Fläche richtig beschriftet ist.\nDie Textplatzierung ist allerdings noch nicht perfekt, daher muss man manuell möglicherweise noch\ndie Texte etwas verschieben. Dass man das nicht mehr tun muss, ist ein Ziel in der zukünftigen\nEntwicklung des Programms, allerdings war das erste Ziel die Korrektheit.\nWenn die thematischen Änderungen bestätigt wurden, kann man die Änderungen in eine XML-Datei\nausgeben („Export DAVID“), die man in der DAVID EQK vor dem Schritt „Bearbeitung“ einlesen kann\n(„NAS-Import“). Beim Einlesen in DAVID bildet DAVID die nötigen Objekte. Somit erspart man sich\neine doppelte Digitalisierung der Flächen und ist gegen Datenverlust bei Programmabstürzen\ngewappnet.\n\n\u003cimg width=\"913\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f115d520-5fa9-4781-be9c-88b5d3107d32\" /\u003e\n\nEbenso stellt diese Arbeitsweise sicher, dass alle Änderungen im Riss in DAVID eingezeichnet werden,\nsodass eine weitere Überprüfung durch einen Mitarbeiter weniger Zeit kostet bzw. überflüssig ist.\nEbenso müssen die Produkte (Änderungsmitteilungen) nur noch oberflächlich überprüft werden, da\ndie Änderungen der Wirtschaftsarten bereits vom Programm errechnet wurde.\nAbgesehen von den vermiedenen Fehlerquellen hat das Programm eine massive Zeitersparnis, welche\nje nach Projektgröße (bei einer regulären Gemarkung mit ca. 500 – 1000 Flurstücken) ca. 60 – 70%\nbedeutet:\n\n- Doppelte Digitalisierung in DAVID / GEOgraf ist überflüssig\n- Änderungen müssen nicht mehr von Hand dokumentiert werden\n- Navigation zu Flurstücken ist wesentlich einfacher als in GEOgraf\n- Legenden, Blattköpfe und Anschlussrisse müssen nicht von Hand erstellt werden\n\nDas höchste Risiko bei der neuen Arbeitsweise ist eine falsche Verschneidung der Teilflächen. Hier ist\näußerste Vorsicht geboten, da die Korrektheit des gesamten Systems daran hängt, ob die Teilflächen\nrichtig verschnitten werden. Allerdings würde diese falsche Verschneidung spätestens im\nVermessungsriss auffallen.\n\n### Potentielle technische Risiken\n\nTechnisch ist die Anwendung nichts Anderes als eine lokale HTML-Seite, daher ist die Anwendung\nauch ohne Internet verfügbar, da kein Server benötigt wird. Systemvoraussetzung ist lediglich ein\nmoderner Webbrowser (Firefox, Edge, Chrome).\n\nDie Anwendung verwendet viele externe Bibliotheken, welche üblicherweise jede einzeln auf Sicherheit\nüberprüft werden müssten. Allerdings verwendet die HTML-Seite einen Trick: der Hauptteil des Codes\nist mit WebAssembly (WASM) umgesetzt. WebAssembly ist ein Bytecode-Format, d.h. der Quellcode\nliegt nicht menschlich lesbar vor (der Code wird zunächst von der Quellsprache C++, oder in\ndiesem Fall: Rust zu WASM kompiliert). WASM hat einen entscheidenden Vorteil: es wird in einer\nSandbox im Browser ausgeführt und hat keine Zugriff auf das Netzwerk, Dateisystem oder die Uhr des\nComputers. Insofern können aus WASM heraus keine Daten versendet werden.\n\nDer JavaScript-Teil der Anwendung besteht zum größten Teil nur aus Aufrufen von WASM-Funktionen,\nHilfsfunktionen sowie Interaktionen für die Benutzeroberfläche. Somit benötigt die Anwendung keinen\nServer, sondern kann komplett lokal laufen und auch einfach kopiert / editiert / ausgetauscht werden.\nDie einzigen externen JavaScript-Bibliotheken sind:\n\n- Leaflet.js (https://leafletjs.com/): quelloffene JS-Bibliothek für interaktive Karten / Web-GIS Systeme)\n- Leaflet.draw (ebenso von den LeafLet-Entwicklern, fügt die Fähigkeit zum Einzeichnen neuer Polygone hinzu)\n- Leaflet.snap (https://github.com/makinacorpus/Leaflet.Snap - entwickelt von der französischen\nGIS-Firma Makina-Corpus, https://makina-corpus.com/): Notwendig, damit beim Digitalisieren\nPunkte direkt auf Linien und Punkt der existierenden Flurstücke einrasten („snapping“).\n\nDie Chance, dass diese JS-Bibliotheken Schadsoftware enthalten, ist sehr gering. Alle Bibliotheken sind\ngebündelt und werden nicht automatisch aus dem Internet bezogen, sondern Updates müssten\nmanuell geschehen.\n\nSoftware-Updates im klassischen Sinne gibt es nicht, da man einfach eine neue Version der HTML-\nSeite im Browser öffnen kann. Die Distribution der Software erfolgt entweder durch einen Link oder\ndurch einen internen Austauschserver. Ebenso könnte die Sicherheit erhöht werden, wenn das Tool\nnicht im Internet zu finden ist, d.h. wenn niemand weiß, dass das Amt dieses interne Tool verwendet,\nkann es also auch nicht angegriffen werden.\n\n### Potentielle organisatorische Risiken\n\nAbgesehen von den technischen Risiken gibt es das organisatorische Risiko, dass z.B. der\nSoftwareentwickler keine Lust mehr hat oder verunglückt oder den Job wechselt. In diesem Fall sind\naber immernoch die GEOgraf und DAVID-Projekte vorhanden, da sich das Programm nicht als Ersatz\nfür GEOgraf und DAVID, sondern als Ergänzung sieht.\n\nOrganisatorisch ändert sich nichts an den Produkten der Bearbeitung der tatsächlichen Nutzung, es\nentsteht lediglich eine zusätzlichen „Auftragsnummer.json“ Datei, die die Änderungen des\nBearbeiters zusätzlich speichert. Hierbei werden auch sensitive Eigentümerdaten in der Datei\ngespeichert, daher ist ein Versenden dieser JSON-Dateien nicht ratsam:\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffschutt%2Ftnviewer","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ffschutt%2Ftnviewer","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffschutt%2Ftnviewer/lists"}