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
Inhaltsverzeichnis
- 1 Farbe und Transparenz Druckwasserzeichen
- 2 automatisiertes Löschen der u_consumeALB/ALK
- 3 erweiterte Shape-Importfunktion
- 4 Exportfunktionen
- 5 Einfärben des Auswahlradius
- 6 Flurstückssuche nach Gemarkungsnummer
- 7 Anzeige der Verfügbarkeit von Diensten
- 8 fehlende Eigentümerangaben im ALB-Auszug
- 9 kvwmap-Datenbank - Trennung von ALK- und Sachdaten in PostgreSQL
- 10 Referenzkarte - wählbare Position
- 11 Strukturierte Namensangabe
Farbe und Transparenz Druckwasserzeichen
--Reißland 14:18, 17. Nov 2006 (CET)
Derzeit ist das Wasserzeichen im Druckrahmen recht kräftig. Schön wäre eine individuelle Einstellung der Transparenz und eventuell auch der Farbe.
automatisiertes Löschen der u_consumeALB/ALK
--Reißland 14:18, 17. Nov 2006 (CET)
Gemäß LiKatAVO M-V §2 Abs.3 können die für Protokollzwecke erfaßten Angaben nach Ablauf von sechs Monaten seit ihrer Erfassung gelöscht werden. Hier wäre ein Automatismus wünschenswert, um die Tabellen u_consumeALB und u_consumeALK nicht unnötig aufzublähen.
erweiterte Shape-Importfunktion
--HolgerR 08:04, 17. Nov 2006 (CET)
Bislang ist es beim Import von Shape-Dateien über den shp2pgsql-Loader von PostGIS nicht möglich anzugeben, in welche Tabellenpalte von PostgreSQL die Tabellenspalte von der dbf-Tabelle des Shape-Files importiert werden soll. Außerdem werden nur Tabellenspalten von 8 Zeichen unterstützt. Schwierig bzw. unmöglich ist es, den Spaltentyp beim Import anzugeben.
Abhilfe schafft hier nur der Import in eine temporäre Tabelle, aus der mittels SQL-Syntax die endgültige Tabelle "gefüttert" wird.
Um diese Vorgehensweise zu erleichtern oder um Shape-Dateien nicht unbedingt von der Betriebssystemebene zu laden, ist sollte der Shape-Daten-Import in kvwmap realisiert werden. Weitere Überlegungen zum Shape-Import
Exportfunktionen
--HolgerR 08:04, 17. Nov 2006 (CET)
Neben dem Export in PDF und der WMS-Definition ist es zur vereinfachten Handhabung besser, in kvwmap eine Exportfunktion zumindest für Shape zu implementieren. Weitere Formate ( z.b. MapInfo, GML, DXF, DWG) entsprechend der Unterstützung von OGR wären noch überlegenswert und sicher sinnvoll.
Einfärben des Auswahlradius
--HolgerR 08:04, 17. Nov 2006 (CET)
Um beim Info-Button 2 (Auswahl im Radius) das von der Auswahl betroffene Gebiet beim Setzen des Mittelpunktes zu erkennen sollte die Auswahlfläche, ähnlich wie bei der Abfrage im Rechteck, transparent gekennzeichnet sein.
Flurstückssuche nach Gemarkungsnummer
--M.Leschke 13,58 16. Nov 2006 (CEST)
Ist es möglich, die Flurstückssuche optional über die Eingabe der Gemarkungsnummer zu organisieren, das erspart langes Scrollen in den Gemarkungsnamenmenüs.
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.
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.
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