Wunsch-Liste

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

erweiterte Druckrahmenverwaltung

--SigridP 17:31, 27. Jun 2006 (CEST) Innerhalb der Druckrahmenverwaltung ist eine Zuordnung der erstellten Druckvorlagen zu den einzelnen Stellen sinnvoll, so dass in der Druckausschnittswahl für jede Stelle nur die entsprechend benötigten Druckrahmen zur Verfügung stehen. Zusätzlich wäre innerhalb der Stelle eine nutzerabhängige Freigabe bestimmter Druckrahmen (z.B. amtlicher ALK-Auszug) wünschenswert.

--HolgerR 18:07, 27. Jun 2006 (CEST)

Der Zuordnung einzelner Druckrahmen zu den einzelnen Stellen kann ich nur zustimmen.

Die Zuweisung von nutzerabhängigen Rechten (hier Freigabe bestimmter Druckrahmen) innerhalb einer Stelle widerspricht dem Konzept der Nutzerverwaltung. Innerhalb einer Stelle sollen all jene Nutzer zusammengefasst werden, die thematisch an einer Aufgabe arbeiten. Sie sollen somit auch die selben Rechte (Kartenebenen, Funktionen, Menues, ..) besitzen. Sofern sich da Unterschiede auftun, sind neue Stellen anzulegen. Wird diesem Konzept so nicht gefolgt, wird die gesamte Nutzerverwaltung bei zunehmenden Nutzern und Stellen wohl recht unübersichtlich.

Von daher ist die nutzerabhängige Freigabe bestimmter Druckrahmen innerhalb einer Stelle aus meiner Sicht nicht notwendig.

Angabe des Koordinatensystems in der Statuszeile

--HolgerR 14:48, 26. Jun 2006 (CEST) Über die Tabelle Rolle kann den Nutzern zu den jeweiligen Stellen das anzuzeigende Koordinatensystem über den EPSG-Code eingestellt werden. Die Koordinatenposition des Mauszeigers wird in dem hier eingestellten Koordinatensystem unter dem Kartenfenster und in der Statuszeile des Browsers angezeigt. Da einige Nutzer diese Angaben nutzen um sie u.a. in eigene Tabellen zu übertragen, ist es wichtig, hinter den Koordinaten das jeweilige Koordinatensystem anzugeben.

Notizen auch für Flächen

--HolgerR 07:40, 19. Jun 2006 (CEST) Neben der Erstellung von Notizen als Punktförmige Objekte ist es m.E. auch sinnvoll, die Notizen auch auf Flächen anwenden zu können, um so z.B. die räumliche Ausdehnung, für die diese Notiz gelten soll, anzuzeigen. Wahlweise soll die Flächengröße dieser Flächennotiz präsentiert werden können.

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 hiweg 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.

Highlighten der Abfragefeatures

--Reißland 07:39, 16. Jun 2006 (CEST) Das abgefragte Feature sollte gehighlightet sein. Bsp: Man stellt den Verlauf von Radwegen als schwarze Linie dar. Dieser Radweg setzt sich aus mehreren Liniensegmenten zusammen. Die Unterteilung in Liniensegmente wird erforderlich, da sich an bestimmten Stellen, bestimmte Attribute ändern (Bsp.: Belagart). Wählt der Nutzer nun einen Teil der Geometrie aus, um die Belagart zu erfahren, erhält er wohl eine Information zum Streckenabschnitt, weiß aber nicht wie weit der Streckenabschnitt eigentlich geht.

Fachschale zur Fortführung von Sachdaten

--Reißland 07:39, 16. Jun 2006 (CEST) Viele Layer verändern nur in großen Intervallen ihre Geometrie (Bsp.: Jagdbezirke). Die Sachdaten hingegen ändern sich häufiger (Bsp.: Telefonnummer des Jägers, Ansprechpartner). Es wäre sinnvoll wenn diese Attribute über eine frei definierbare Eingabemaske durch den jeweiligen Sachbearbeiter direkt in der PostgresDB aktuell gehalten werden könnten.

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

Vielleicht eignet sich aber auch schon ein kostenfreies GIS wie z.B. der Spatial Commander? Der erlaubt das Lesen und Schreiben von einer bzw. in eine PostGIS-DB. Hast Du das mal ausprobiert?

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

Löschen gespeicherter Kartenausschnitte

--Markus Hentschel 14:22, 11. Apr 2006 (CEST) Im Moment (1.5.9) ist es nicht möglich, gespeicherte Kartenausschnitte auch wieder zu löschen. Ist das geplant oder schon in Entwicklung?

Zoom auf Flurstück mit Mindestmaßstab

Es wäre gut, wenn beim Zoomen auf ein Flurstück ein in der config.php zu definierender Mindestmaßstab nicht unterschritten würde, da man sonst außerhalb des sichtbaren Bereichs (z.B. unter 1:50) gelangen kann und das Kartenbild weiß bleibt.

Änderungen in config.default.php

--Heinz Schmidt 13:35, 5. Apr 2006 (CEST)
Änderungen in der config.default.php könnte man durch Kommentare kennzeichnen.

z.B.:

define("REFMAPFILE",SHAPEPATH.'MapFiles/refmapfile.map'); # Version 1.5.9

dadurch wäre es leichter die eigene config.php jeweils auf die aktuelle Version anzupassen.

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.

Trennung von Funktionen und Daten

• Wie ja jeder Nutzer von kvwmap weiß, gibt es einige Daten bzw. Dateien, die der Benutzer selber zur Anwendung hinzufügen kann oder anpassen kann. Das betrifft beispielsweise Bilder für Wappen oder auch Dokumentenköpfe und Snippets. Das ist soweit auch in Ordnung nur gibt es ab und an Probleme, wenn es um das Upgrade geht. Dann müsste ein Nutzer selber dafür sorgen, dass seine Änderungen wieder hergestellt werden. Darum wäre es besser, wenn alle Änderungen oder Zusätze in einem exterenen Verzeichnis wie das data-Verzeichnis abgelegt werden.

--Rahn 14:30, 11. Apr 2006 (CEST)

Es wurde folgendes Konzept zur Trennung von nutzerspezifischen und kvwmap-internen Daten entwickelt:

• In jedem der Ordner fonts, graphics, snippets und symbols gibt es einen Unterordner custom.
• Diese custom Ordner sind in jeder neuen Version von kvwmap leer.
• Nutzer können nun in diesen Ordnern eigene Snippets, Grafiken, Symbole usw. erstellen und auch kvwmap-interne Daten hinein kopieren und verändern.
• Beim Update auf eine neue Version wird das alte kvwmap-Verzeichnis kopiert, der Name des Verzeichnisses entsprechend der neuen Version umbenannt und die neue kvwmap-Version in dieses Verzeichnis entpackt. Dabei werden die kvwmap-internen Dateien überschrieben und die nutzereigenen Daten in den custom-Ordnern bleiben bestehen.

An dieser Stelle sei nochmal darauf hingewiesen, dass sich nutzerspezifische Snippets, Grafiken, Symbole usw. nur einbinden lassen, wenn diese entweder in der config.php oder in der Datenbank definiert werden können.

Stelle kopieren

• Es wurde der Wunsch geäußert, dass man eine Stelle kopieren können sollte. Dabei würden dann alle Eintragungen einer Stelle auf eine neue übertragen incl. der Zuordnungen zu Layern, Menüs und Benutzern etc. Vorteil wäre die Zeitersparniss, wenn man eine ähnliche Stelle einrichten müsste. Dann würde man nur diese kopieren und die Änderungen vornehmen, was einfacher wäre als eine neue komplett neu aufbauen zu müssen.

--Rahn 11:30, 15. Mär 2006 (CET)

Um eine Stelle zu kopieren, wählt man diese in der Stellenverwaltung aus. Die Daten der Stelle werden im Stelleneditor angezeigt. Man kann nun den Namen und auch andere Attribute der Stelle ändern und klickt anschließend auf 'Als neue Stelle eintragen'. Es wird eine neue Stelle erzeugt, die die gleichen Zuordnungen zu Layern, Menüs und Benutzern besitzt, wie die alte Stelle. Diese Funktion ist in der Version 1.5.8 vollständig implementiert.

Browserfunktionalität

• Bei einigen Benutzern ist mir aufgefallen, dass sie gerne mal den "Zurück"-Button des Browsers verwenden, um zu einer Seite, z.B. zur Karte nach einer Suche, zurückzukehren. Dabei können dann merkwürdige Dinge passieren. Natürlich wird das der Anwendung angekreidet und nicht der falschen Bedienung. Kann kvwmap nicht die ganze Browserfunktionalität wegblenden? --Markus Hentschel 07:00, 24. Feb 2006 (CET)

---

• ein solcher eingriff in die individuellen einstellungen des eigenen browsers wird von vielen als mindestestens ebenso unangenehm betrachtet (auch von mir).

→ aber umsetzbar waere es natuerlich...

PS: vielleicht hilft hierbei auch der zukuenftig neue interne "Zurück"-Button von kvwmap...

Navigationsleiste des SVG-Clients

gruesse--Hauke 09:07, 27. Feb 2006 (CET)

Funktionen in der Sachdatenanzeige Flurstück

--Markus Hentschel 14:10, 24. Feb 2006 (CET)

• Zur Vereinheitlichung des Aussehens schlage ich vor, die beiden snippets flurstueckssuche.php und Flurstücke.php anzugleichen. Dabei geht es mir zunächst mal nur um die Links am unteren Ende des snippets. Ich schlage vor, zwei Reihen zu definieren.
  • In der ersten Reihe: "zur Flurstückssuche", "zur Adresssuche", "zur Namenssuche", "Kartenausschnitt"
  • Die zweite Reihe ist dann für die Ausdrucke Format 30 und 35, mit und ohne Wasserzeichen
  • Später könnte eine dritte Reihe dazu kommen mit Format 20, 25 und 40
• Für mich hab ich das schon umgesetzt, das sieht bei mir so aus:

Eine erste Reihe:

 <tr align="center" valign="top" bgcolor="<?php echo BG_DEFAULT ?>">
   <td colspan="2">
   <a href="index.php?go=Flurstueck_Auswaehlen&searchInExtent=<?php echo $this->searchInExtent;
     ?>&GemID=<?php echo $this->flst[$i]->GemeindeID;
     ?>&GemkgID=<?php echo $this->flst[$i]->GemkgSchl; ?>&FlurID=<?php echo $this->flst[$i]->FlurID;
     ?>&FlstID=<?php echo $this->flst[$i]->FlurstKennz; ?>">zur Flurstückssuche</a> |
     <a href="index.php?go=Adresse_Auswaehlen&searchInExtent=<?php echo $this->searchInExtent;
     ?>&GemID=<?php echo $this->formvars['GemID'];
     ?>&StrID=<?php echo $this->formvars['StrID'];
     ?>&HausID=<?php echo $this->formvars['HausID'];
     ?>">zur Adresssuche</a> |
     <a href="index.php?go=Namen_Auswaehlen&name1=<?php echo $this->formvars['name1'];
     ?>&name2=<?php echo $this->formvars['name2'];
     ?>&name3=<?php echo $this->formvars['name3'];
     ?>&name4=<?php echo $this->formvars['name4'];
     ?>&bezirk=<?php echo $this->formvars['bezirk'];
     ?>&GemkgID=<?php echo $this->flst[$i]->GemkgSchl;
     ?>">zur Namensuche</a>
     <?php
       if ($this->flst[$i]->isALK) {
       ?> | <a href="index.php?go=ZoomToFlst&FlurstKennz=<?php echo $this->flst[$i]->FlurstKennz; ?>">
         Kartenausschnitt</a><?php
       }
     ?>
usw.

Und einen zweite Reihe:

 <tr align="center" valign="top" bgcolor="<?php echo BG_DEFAULT ?>">
   <td colspan="2">
   <?php
     $this->getFunktionen();  
     if ($this->Stelle->funktionen['ohneWasserzeichen']['erlaubt']) {
     ?><a href="index.php?go=ALB_Anzeige&FlurstKennz=<?php echo $this->flst[$i]->FlurstKennz; ?>
      &formnummer=30&wz=0" target="_blank">ALB-Auszug 30</a> | 
     <?php
     ?><a href="index.php?go=ALB_Anzeige&FlurstKennz=<?php echo $this->flst[$i]->FlurstKennz; ?>
      &formnummer=30&wz=1" target="_blank">ALB-Auszug 30 mit WZ</a>
     <?php
      }
     if ($this->Stelle->funktionen['ALB-Auszug 35']['erlaubt']) {
       if ($this->Stelle->funktionen['ohneWasserzeichen']['erlaubt']) {
       ?> | <a href="index.php?go=ALB_Anzeige&FlurstKennz=<?php echo $this->flst[$i]->FlurstKennz; ?>
        &formnummer=35&wz=0" target="_blank">ALB-Auszug 35</a>
       <?php }
     ?> | <a href="index.php?go=ALB_Anzeige&FlurstKennz=<?php echo $this->flst[$i]->FlurstKennz; ?>
      &formnummer=35&wz=1" target="_blank">ALB-Auszug 35 mit WZ</a>
     <?php }
     ?>
usw.

Für die Flurstücke.php dann analog. Außerdem habe ich die Beschriftung bei "ohne Wasserzeichen" geändert, weil mir das unlogisch erscheint. Der ALB-Auszug im Format 30 oder 35 ist der amtliche Auszug, daher sollte im Snippet der amtliche Auszug auch nur "ALB-Auszug" heißen und nicht "ALB-Auszug ohne WZ".

Wäre das ein Vorschlag zur allgemeinen Übernahme?

Notizen

• --Markus Hentschel 07:49, 28. Feb 2006 (CET) Momentan werden die erzeugten Notizen in jeder Stelle jedem user angezeigt. Das ist nicht sinnvoll. Es muss Eingrenzungen geben, was die Verfügbarkeit der Notiz angeht. Mein Vorschlag ging dahin, über eine zu schaffende Kategorie "Verfügbarkeit" o.ä. zu unterteilen in
  • Notizen, die nur der erzeugende User selbst sieht,
  • Notizen, die alle User der Stelle sehen, in der der erzeugende User die Notiz angelegt hat,
  • Notizen, die grundsätzlich alle Mitarbeiter sehen.

Es gab von Peter noch einen anderen Vorschlag, den er vielleicht hier nochmal hinschreibt. Vielleicht gibt es noch andere Ideen?

• Außerdem sollte in jeder Notiz auch immer der Name des erzeugenden Users stehen sowie das Datum der Erzeugung der Notiz.

Darstellung mehrere Layer unter einer Auswahlbox

• (Holger Riedel) Es sollte möglich sein, mehrere Layer unterschiedlicher Geometrietypen in kvwmap so hinterlegen, dass ich nur einen Themen-Ein/Aus-Schalter betätigen muss, um diesen ganzen Komplex entweder aktiv oder inaktiv zu schalten. Ich möchte den Gebäudelayer so aufbrezeln, dass ich neben der Definitionsgeometrie (Typ Multipolygon)auch noch die Ausgestaltungsgeometrie (Typ Multilinestring) anzeigen kann, ohne diese Ebene noch extra ein- bzw. auszuschalten.
  • --Markus Hentschel 14:45, 1. Mär 2006 (CET) Der UMN kann das meiner Meinung nach(siehe [1]). D.h., wenn zwei Layer denselben Namen haben, wird das in der Legende wie ein Layer behandelt. Ob das auch bei Layern mit unterschiedlichen Geometrietypen funktioniert, weiß ich nicht.