Wunsch-Liste

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

zur ToDo-Liste

Anzahl Treffer in der Sachdatenanzeige Flurstück

--Markus Hentschel 12:41, 9. Mär 2007 (CET) Die Anzeige der Flurstücke in der Sachdatenanzeige ist per LIMIT begrenzt, was die Anzeige angeht. Wenn das Limit überschritten wird, muss es eine Möglichkeit geben, die nächsten Flurstücke aufzurufen.

Sortierung in der Namenssuche

--Markus Hentschel 12:41, 9. Mär 2007 (CET) In der Namenssuche bekommt man nach der Suche eine Trefferliste, von der aus man zur Anzeige des ALB oder der Karte weitergehen kann. Schön wäre es, wenn man die Möglichkeit hätte, diese Suchliste nach allen angezeigten Attributen zu sortieren. Entweder schon bei der Suche selbst, indem eine Auswahlliste angeboten wird, oder indem man auf die Überschriften klicken kann und die Sortierung dann nach der angeklickten Überschrift auf- bzw. absteigend erfolgt.

ALKIS

--Markus Hentschel 14:14, 2. Mär 2007 (CET)
So ganz allmählich wirft ALKIS seine Schatten voraus. Der Tag wird kommen, da es ALK und ALB nicht mehr gibt. Für diesen Tag muss kvwmap gerüstet sein. Es muss dann ein vollständiges "ALKIS-Schema" für die PostGIS-DB existieren und sämtliche SQL-Zugriffe auf ALKIS müssen dann geändert vorliegen. Noch ist der Tag X weit entfernt, aber kvwmap muss die Umstellung auf ALKIS per Knopfdruck ebenfalls mitmachen. Es muss also rechtzeitig vorher mit den entsprechenden Umbauarbeiten begonnen werden...

Funktionen "ALB-Auszug 20" und "ALB-Auszug 25"

--Markus Hentschel 14:09, 2. Mär 2007 (CET) Genau wie bei den ALB-Formaten 35 und 40 sind auch die Formate 20 und 25 zu schützen. Der zugriff muss explizit erlaubt werden. Daher sind die entsprechenden Funktionen in der Tabelle u_Funktionen nötig.

kvwmap look&feel

--Markus Hentschel 14:44, 13. Feb 2007 (CET)
Was die Benutzerfreundlichkeit angeht, kann kvwmap an einigen Stellen noch zulegen. Die User vergleichen natürlich immer mit anderen Programmen, im Fall von kvwmap vor allem mit der ALK-Auskunft des LaiV. Dabei werden folgende Punkte genannt:

• Das Kartenbild ist zu klein, bzw. die Menüspalte auf der rechten Seite nimmt zuviel Platz weg. Könnte man die Menüs nicht als Pull-Down-Menüs und/oder Buttons realisieren? Die Themenauswahl/Legende müsste dann auf die linke Seite wandern. Wird die Übersichtskarte überhaupt gebraucht???
• Das Drucken geht sehr langsam. Das ist natürlich zum Teil dem Netz geschuldet, durch die das PDF muss. Man könnte das Ganze abkürzen, indem schon in der Druckvorschau die Alternativen "Speichern" bzw. "Drucken" möglich sind. Bei "Drucken" wird direkt an den (Standard-)Drucker geschickt.
• Man erfährt nicht, welche Daten alle in die Stelle eingebunden sind. Die Themenauswahl sollte alle Themen anzeigen, auch die, die im aktuellen Maßstabsbereich nicht sichtbar sind.
• Die vorhandenen Suchmöglichkeiten könnten alle unter einem Button/Pulldown "Suche" o.ä. in einer Maske mit mehreren Registerkarten vereinigt werden.

Festpunktverwaltung Meridianstreifen übergreifend

--Michael Leschke 07.22, 24. Jan 2007 (CET) Für unser Amt (Mecklenburg Strelitz) ist es wichtig, daß die Festpunktverwaltung auch in zwei Meridianstreifen funktioniert, da unser Bearbeitungsgebiet im 4. und 5. Streifen liegt. Weiterhin würde ich es, wie bereits in Bad Doberan angespochen, gut finden, wenn auch PDF-Dateien als Festpunktbild genutzt werden können, da ja die TP's auf CD in diesem Format vorliegen.

Speicherung im generischen Layereditor

--Markus Hentschel 12:33, 16. Jan 2007 (CET) Wenn der User Daten über den generischen Layereditor ändert, wäre es gut, wenn er eine Meldung über das erfolgreiche Ändern bekäme, z.B. "Änderung erfolgt!" oder so was.

Sortierung der User im Stelleneditor

--Markus Hentschel 12:33, 16. Jan 2007 (CET) Könnte die Anzeige der User nicht nach dem Muster "Name, Vorname" stattfinden? Die Suche würde (noch mal) deutlich schneller.

alphabetische Sortierung mit Umlauten

--Markus Hentschel 07:33, 8. Jan 2007 (CET) alphabetisch sortierte Listen wie z.B. die Gemarkungsauswahl in der Flurstückssuche sollten auch die Umlaute an die richtige Stelle sortieren und nicht am Ende der Liste aufführen.

Neugestaltung der Legende

--Markus Hentschel 15:06, 4. Dez 2006 (CET) Ich möchte eine Diskussion über die Legende anregen. Meiner Meinung nach ist die jetzige Legende noch deutlich verbesserungwürdig. So ist es z.B. nicht möglich, Gruppennamen zu verwenden, die Sonderzeichen enthalten, z.B. ein simples Leerzeichen (und nbsp; schafft keine Abhilfe). Wenn man von der jetzigen Legende abgeht, die ja vom Mapserver erzeugt wird, erhält man ganz sicher eine Menge Gestaltungsmöglichkeiten.

--Reißland 11:22, 13. Dez 2006 (CET) Bei meiner Tour duch die Ämter ist mir aufgefallen, dass besonders Nutzer die nicht so häufig mit dem Programm arbeiten, Probleme mit dem Darstellungsbereich haben (minscale, maxscale). Viele Daten bleiben im verborgenen oder werden nur zufällig entdeckt. Oftmals werde ich auch gefragt, warum Daten mal zu sehen und mal nicht zu sehen sind. Um dieser Problematik entgegenzuwirken, sollten aus meiner Sicht in den Gruppen generell alle verfügbaren Datensammlungen aufgelistet werden (Liste wird dann natürlich entsprechend lang). Daten die im aktuellen Maßstab nicht dargestellt werden können, sollten in der Legende hellgrau erscheinen. Optional könnte auch der Darstellungsbereich unter dem Layernamen aufgeführt werden. Wie seht ihr das?

--Markus Hentschel 13:48, 13. Dez 2006 (CET) Das Problem habe ich auch. Ich habe es etwas abgefangen durch eine Liste der Gruppen und Themen, die ich auf meiner internen Portalseite veröffentliche. Das Problem wird nur dadurch gelöst, dass immer alle Themen angezeigt werden, so wie Hendrik schreibt. Der große Nachteil ist die Länge der Legende. Wegen dieser Länge wurde die Legende in der jetzigen Form ja überhaupt erst so aufgebaut.

--Markus Hentschel 12:07, 15. Dez 2006 (CET) Ich komme da wieder gerne auf meinen Vorschlag zurück, Legende und Themenauswahl voneinander zu trennen. Dann kann die Themenauswahl so lang sein wie sie will und immer alle Themen zeigen (die nicht aktiven z.B. ausgegraut) und die Legende bringt immer nur die aktuell sichtbaren Layer. Es könnte z.B. über zwei Buttons in der Navileiste laufen oder über Tabs, z.B. so:

Datei:tabs layer legende.png

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.

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?