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

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.

Koordinatenanzeige Flurstück

--Markus Hentschel 08:07, 19. Dez 2006 (CET) Bei der ALK-Auskunft vom LaiV wurde auch schon mal die Diskussion geführt, ob man die Koordinate eines digitalisierten (und damit möglicherweise um ein paar Meter ungenauen) Punktes mit Millimetergenauigkeit anzeigen soll. Die klare Antwort war nein. Entsprechend würde ich auch für kvwmap vorschlagen, dass digitalisierte Punkte (Folie 085) nur mit Dezimeter angezeigt werden. Vermessene Punkte (Folie 052) sollten meiner Meinung nach nur mit Zentimeter angegeben werden, da der Millimeter rechtlich nicht gesichert und auch nicht relevant ist.

Stellenabhängige Transparenzeinstellungen von Layern in 'used_layer'

--HolgerR 11:33, 15. Dez 2006 (CET) Neben der stellenabhängigen Maßstabseinstellung in der Tabelle 'used_layer' ist es wünschenswert, für bestimmte Stellen die Transparenz von Layern individuell einzustellen.

Sachdatenanzeige ALB

--Markus Hentschel 13:42, 13. Dez 2006 (CET) Meiner Meinung nach muss der Eigentümer in der Sachdatenanzeige selbst (d.h. nicht erst durch Erzeugen eines entsprechenden PDFs) erscheinen. Das würde den Zugriff enorm beschleunigen und es wird auch immer wieder angemeckert, dass man nur relativ zeitaufwändig über das PDF an den Eigentümer kommt. Leider können es durchaus sehr viele Eigentümer zu einem Flurstück sein. Wäre es sinnvoll, in die Sachdatenanzeige einen Link "Eigentümer" o.ä. einzubauen? Wenn man auf diesen Link klickt, werden die Eigentümer aufgelistet.

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.

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.

--HolgerR 08:03, 20. Nov 2006 (CET)

Mögliche Lösung siehe: u_consumeALB und u_consumeALK

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.

--Markus Hentschel 14:59, 4. Dez 2006 (CET) Ganz toll wäre es, wenn man den Bereich, der herausgeholt werden soll, räumlich eingrenzen könnte, indem man ein Polygon zeichnet. Oder weitere Option: der aktuelle Kartenausschnitt begrenzt die Ausgabe räumlich.

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.

--Markus Hentschel 15:01, 4. Dez 2006 (CET) Hier wäre zu diskutieren, wie und wo weitere Eingabefelder sein sollten. Z.B. sollte meiner Meinung nach eine Eingabe der Gemeindenummer in der Adresssuche ebenfalls möglich sein.

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.

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