Wunsch-Liste

Ideen für zukünftige Entwicklungen, Diskussion über geplante Entwicklungen. Bei allgemeinem Konsens werden diese Punkte in die ToDo-Liste aufgenommen.

zurück zur ToDo-Liste

Neue Zeichenwerkzeuge

--SigridP 11:59, 9. Nov 2006 (CET)Die in den Fachschalen Flächenversiegelung und Jagdkataster hinzugefügten Zeichenwerkzeuge 'Flurstuecke hinzufuegen' und 'Flurstuecke entfernen' wären auch für die Fachschalen Bodenrichtwerterfassung und Bauleitplanung nützlich.

History back nicht beim selben Kartenausschnitt

--Markus Hentschel 10:34, 7. Nov 2006 (CET) Wenn ein neuer Kartenausschnitt geometrisch mit dem vorhergehenden identisch ist (z.B. nach Sachdatenabfragen oder beim neu laden), dann sollte dieser neue Kartenausschnitt beim Klick auf History back oder forward nicht auftauchen.

Namenssuche im ALB

--SigridP 11:00, 3. Nov 2006 (CET)Bei der Namenssuche ist in der erzeugten Auflistung die Spalte „Jagdkataster“ m.M.n. ungünstig und in den meisten Fällen auch nicht erforderlich. Hier schlage ich vor, diesen Link nur in eine Stelle einzubinden, in der auch die Bearbeitung des Jagdkatasters vorgenommen wird.

--Rahn 11:02, 6. Nov 2006 (CET) erledigt. Es gibt in Version 1.6.3 eine neue Funktion 'Jagdkataster', über die man die Einblendung der Spalte steuern kann.

Sachdatenabfrage im Polygon

--HolgerR 15:06, 24. Okt 2006 (CEST) Neben der Sachdatenauswahl in der Karte durch Klick bzw. Aufziehen eines Rechteckes ist es wünschenswert, wenn das Werkzeug zum Zeichnen von Polygonen genutzt werden kann, um die Sachdatenauswahl innerhalb eines Polygones auszuführen.

erweiterte Suchfunktion nach Flurstücken

--SigridP 16:28, 19. Okt 2006 (CEST)In der Version 1.6.2 ist jetzt ein Mehrfach-ALB-Ausdruck möglich, der bei der Suche über die Karte und über Namens- und Adressensuche gut funktioniert. Jedoch ist bei Vorgabe bestimmter Flurstücke, die über die Karte nicht auswählbar sind (da ALK nicht flächendeckend vorhanden ist oder über den I-Button eine genaue Auswahl nicht möglich ist)eine gemeinsame Auflistung nicht möglich. Hier wäre es gut, wenn man über die Flurstückssuche mehrere Flurstücke auswählen und durch eine Suchabfrage diese gemeinsam anzeigen und ausdrucken könnte.

Layer- und Userauswahl im Stelleneditor

--Markus Hentschel 16:02, 17. Okt 2006 (CEST) Bei vielen Layern und vielen Usern ist es praktisch unmöglich, einen Layer bzw. einen User aus den jeweiligen Listen auszuwählen. Hier wäre es schön, wenn diese beiden Listen alphabetisch sortiert würden.

Anzeige der Verfügbarkeit von Diensten

--Markus Hentschel 11:15, 17. Okt 2006 (CEST) Bei als WMS oder WFS eingebundenen Layern wird einfach nichts angwezeigt, wenn der Dienst aus irgendwelchen Gründen gerade nicht zur Verfügung steht. Ich könnte mir vorstellen, dass man eine "Ampel" hinter solchen Themen anzeigt, die als WMS/WFS eingebunden sind. Grün, wenn der Dienst da ist, sonst rot. Im Hintergrund müsste kvwmap alle paar Minuten einen Request machen und darüber prüfen, ob der Dienst vorhanden ist.

Ausgabe Stand der ALB-Daten im ALB-Druck

--Heinz Schmidt 10:46, 10. Okt 2006 (CEST)
Damit der Stand der Fortführung der ALB-Daten ersichtlich ist, schlage ich vor unter der Zeile "Datum" im ALB-Druck den "Stand" auszugeben, der aus der tabelle "alb_fortfuehrung", Spalte "ffzeitraum_bis" aus der postGIS DB kommen sollte. Habe die Zeile jetzt schon in die alb.php eingefügt und trage das Datum nach der Fortführung manuell ein.

Die Ausgabe sieht so aus:

  Datum 10.10.2006 09
  Stand: 07.09.2006

--Markus Hentschel 14:21, 17. Okt 2006 (CEST) Dasselbe sollte auch in der Namenssuche und der Sachdatenanzeige (flurstuecksanzeige.php) stehen.

Großformatige Druckrahmen

--Heinz Schmidt 09:14, 10. Okt 2006 (CEST)
Es sollten auch großformatige Drucke (A2 bis A0) mit kvwmap über Druckrahmen zu erzeugen sein.
Gefordert wird das z.B. im Bereich der Liegenschaftsverwaltung.

--Markus Hentschel 11:11, 17. Okt 2006 (CEST) Das war bei der Entwicklung der Druckfunktionalität in Richtung ALK-konformer Druck nicht dabei, wir hatten uns bewußt auf A4 und A3 als Standardausgaben beschränkt. Ich weiß nicht, wie es mit der Performance ist, wenn man Drucke größer A3 erzeugt. Das sind dann unter Umständen doch ziemliche Klopse, die da durch die Leitungen wollen.

fehlende Eigentümerangaben im ALB-Auszug

--SigridP 12:48, 22. Sep 2006 (CEST)
Der im Original-ALB-Auszug zu den Privatpersonen angegebene Zusatz "GbR ......", "Erbengemeinschaft", "zu je 1/2 Anteil" usw. ist im kvwmap-Auszug nicht enthalten. Dieser ist jedoch lt. Aussagen der zuständigen Mitarbeiter unbedingt erforderlich. Beim Durchforsten der postgresql-DB habe ich diesen Eintrag in der tabelle alb_grundbuecher in der Spalte zusatz_eigentuemer entdeckt.

Verbesserung der Festpunktverwaltung

--Heinz Schmidt 11:01, 12. Jul 2006 (CEST), geändert --Heinz Schmidt 09:45, 23. Okt 2006 (CEST)
-Die Festpunktverwaltung beinhaltet eine Funktion in einer Suchergebnisliste, einen Link anzuklicken und dann eine Vorschau auf die entsprechende Einmessungsskizze zu erhalten. Für diese Vorschau ist es erforderlich, dass die Skizze im PNG-Format vorliegt. Andere Dateiformate werden hierfür momentan nicht unterstützt.
Für recherchierte Festpunkte können die Einmessungsskizzen zu Aufträgen hinzugefügt werden. Hierfür ist es erforderlich, dass die Skizzen zusätzlich im TIFF-Format vorliegen.
Der Verbesserungsvorschlag geht dahin, dass die Einmessungskizzen zukünftig im PDF-Format von kvwmap verwaltet werden; für die Vorschau und für die Zusammenstellung von recherchierten Festpunkten. Eine redundante Ablage in PNG und TIFF würde damit entfallen. Eine dateiformat-unabhängige Verwaltung der Einmessungskizzen, wie z.B. bei der Rissverwaltung, wäre auch zu diskuttieren. Mir würde aber das PDF-Format ausreichen.

Dieser Vorschlag ist in dem Zusammenhang zu sehen, dass das LAIV den Kreisen im Lande z. Zt. die TP-Beschreibungen im qualitativ hochwertigen PDF-Dateien zur Verfügung stellt. Diese können in der Form in KVWMAP momentan leider nicht verarbeitet werden.

Peter Korduan hierzu: "die Aufwendung für die Umstellung auf variable Datentypen schätze ich mit 2 Tagen ein. Machbar sollte es aber sein. Gerade pdf wird ja von den Browsern gut unterstützt. Es ist nur an einigen Stellen im Quellcode einzutragen, dass variable Typen verwendet werden. Die Unterscheidung sollte die Anwendung dann selbständig an Hand der Dateiendungen vornehmen können."

--HolgerR 14:02, 24. Okt 2006 (CEST)

• Die Trennung der AP-Beschreibungen im TIFF- bzw. PNG-Format erfolgte aus Gründen der Performance bei der Vorschau der eingescannten AP-Beschreibungen im Browser.

Die Formate für die Abspeicherung der Dateien, sowohl AP-Beschreibungen als auch die Vorschau, sollten nicht vorgegeben werden, da wir so auch für zukünfige Dateiformate offen sind. Vielleicht wäre es sinnvoll, die Vorschaudateien in einen Ordner unterhalb des Kilometerquadratordners der Festpunkte zu hinterlegen. In der config.php kann ja dann hinterlegt werden, ob standardmäßig Vorschaudateien vorhanden sind und wo sie abgelegt sind. Damit besteht dann auch die Möglichkeit, die eigentlichen AP-Beschreibungen als Vorschaubild zu laden.

• Die Ergebnistabelle der Punkte kann m.E. reduziert werden. Notwendig sind aus unserer Sicht folgende Spalten:

Punktkennzeichen, RW, HW, Höhe, VMA, Vorschau, Anzeige, ZST, ENT, LAH, LG, LZ, HG, HZ, HAH

• Beim Hinzufügen der Festpunkte zu den Anträgen bleibt standardmäßig die Zuordnung der bisher zu dem Antrag hinzugefügten Festpunkte erhalten. Manchmal ist es aber notwendig, die bisher zugeordneten Punkte aus dem Antrag zu löschen. Dafür besteht bis jetzt innerhalb von kvwmap noch keine Möglichkeit. Das ist nur auf der Datenbankebene möglich.

Um dies zu realisieren sollte in der Maske 'Festpunkte zum Auftrag hinzufügen' die jeweilige Option auswählbar sein. Als Standard ist das Hinzufügen einzustellen.

• Wird bei der Auswahl der Festpunkte in der Karte ein Orientierungspunkt ohne dazugehörigen TP ausgewählt, muss in der Ergebnisliste auch der TP erscheinen, da sonst die TP-Beschreibung, auf der der OP in aller Regel nachgewiesen ist, nicht mit herausgesucht wird und somit nicht zu den Anträgen hinzugefügt wird.
• Für viele Aufgaben ist es wichtig, die Punkte in der Karte nicht nur im Rechteck, sondern auch innerhalb eines Polygons herauszusuchen. Dies ist aber sicherlich eine allgemeinere Funktion, die ich an anderer Stelle einfügen werde.

kvwmap-Datenbank - Trennung von ALK- und Sachdaten in PostgreSQL

--HolgerR 07:40, 19. Jun 2006 (CEST) Bei Änderungen in der Datenstruktur von EDBS2WKT muss grundsätzlich eine neue ALK-Datenbank angelegt werden, wie z.B. von der Version 1.6 zu 1.7. Das Handling zur Wiederherstellung und Nutzung der kvwmap-Datenbank ist zu umständlich, da die Sachdaten aus der alten kvwmap-Datenbank in die neue ALK-Datenbank eingelesen werden müssen um als neue kvwmap-Datenbank genutzt zu werden. Während dieser Zeit, Backup und Restore der alten kvwmap-Datenbank, dürfen keine Änderungen an den Daten vorgenommen werden, d.h. die Einarbeitung von Daten (Dokumentenverwaltung, Notizen, etc.) muss zu dieser Zeit ruhen.

--Markus Hentschel 14:46, 20. Jun 2006 (CEST)

Vielleicht sogar eine Trennung in 3 Datenbanken: ALK- ALB- und Geometriedatenbank?

--Pkorduan 17:47, 21. Jun 2006 (CEST)

Hier hilft sicher ein Skript, welches ein Backup nur von kvwmap-relevanten Datentabellen macht. Mir schwebt da vor, das das Backupskript das Skript zum Anlegen der Datenbank (postgis_install.sql) durchsucht nach CREATE Einträgen und den dazugehörigen Tabellennamen und anschließend zu jedem dieser Tabellen ein Dump mit oder ohne Daten anfertigt.

Andere Möglichkeit wäre ein Skript, welches alle ALK relevanten Tabellen vom EDBS2WKT Konverter löscht. Gab es da nicht mal was von Herrn Jäger? Wenn man also seine Datenbank von ALK-Tabellen befreit hätte, könnte man diese als Template zum Anlegen einer neuen ALK-Datenbank angeben und hätte schon alles von kvwmap drin.

Die Geschichte mit mehreren Datenbanken ginge vom Prinzip her auch, jedoch müßte man dann Joins über Datenbanken hinweg machen. Das ist schlecht. Über Schemas hinweg würde ja noch gehen, aber die liegen immer in ein und der selben Datenbank.

--HolgerR 15:27, 26. Jun 2006 (CEST)

Der 2.Tipp, alle relevanten Tabellen des EDBS2WKT-Koverters zu löschen (richtig, zu EDBS2WKT ist ein entsprechendes SQL-Skript beigelegt) und diese Datenbank dann als Template zu nutzen sollte vom Handling her funktionieren.

Herr Jäger hat ja die Version 1.7 vom EDBS2WKT-Konverter freigegeben, da ist das ein willkommener Anlass das Handling zu testen.

Nur die Benutzung der DB muss zu dieser Zeit ja trotzdem gesperrt werden, da ja die alte DB als Template dient und die neue DB einen anderen Namen erhalten muss. Nach Anlegen der DB, oder vielleicht schon vorher, sollten die alte und die neue DB umbenannt werden, damit in der config.php und der Layerverwaltung keine Änderungen vorgenommen werden müssen.

Sind die Laufzeitprobleme bei Joins über Datenbanken hinweg so gravierend, dass man lieber die Sperrung der Datenbank für eine gewisse Zeit in Kauf nehmen sollte?

Referenzkarte - wählbare Position

--HolgerR 07:40, 19. Jun 2006 (CEST) Ähnlich wie bei der Positionierung des Wappens soll die Position der Referenzkarte einstellbar sein. Damit wird gewährleistet, dass bei vielen Menüeinträgen die Referenzkarte auch weiterhin sichtbar ist.

• Oben, unterhalb des Wappens oder,
• Unten, überhalb des Wappens.

Strukturierte Namensangabe

--HolgerR 16:34, 9. Mai 2006 (CEST)
In Hinblick auf die ALKIS-Migration ist es notwendig, das die Namensangaben in die Strukturierte Namensangabe überführt werden. Durch die Strukturierte Namensangabe weiter

Downloadmöglichkeit für Rechercheergebnisse der Nachweisverwaltung

- von Heinz Schmidt LWL/SN
Diese Funktion wäre Nützlich, wenn man am Client keinen Zugang auf das Dateisystem des Servers hat, wie es normalerweise ist.