Wunsch-Liste

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

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.

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 sind Änderungen in der Präsentation der Adressangaben bzw. beim Einlesen der WLDGE-Daten notwendig.
Die Verschlüsselung der strukturierten Namensangabe lässt sich gut aus der Übersicht des Landesvermessungsamtes Baden-Württemberg auf dem Arbeitsblatt 'Seite4-Dateikennung2' erkennen StrutkurierteNamensangabe
Ich möchte folgende Verfahrensweisen zur Diskussion stellen:

• Übernahme der Satzunterarten 1 - 4 wie gehabt in die Tabelle alb_g_name.
• Ist die Satzunterart 1 nicht vollständig mit Name, Vorname, Namensbestandteile, akademische Grade gefüllt, sind die Kommas zu löschen
• Adresse mit Postfach und keine Angabe von Straße Hausnummer in Satzunterart 3
  • Wenn Postleitzahl Briefadresse (PLZ) in Satzunterart 4 gefüllt ist, wird die Postleitzahl Postfach (PLZPF) anstelle der PLZ eingefügt und aus der Satzunterart 3 gelöscht, Einfügen der Kennung 'PF' in das Feld Straße
  • Ist die PLZ nicht gefüllt, Übernahme der PLZPF nach Satzunterart 4 und Löschen in Satzunterart 3, Einfügen der Kennung 'PF' in das Feld Straße
• Adresse mit Postfach und Angabe von Straße Hausnummer in Satzunterart 3 --> Ausblenden der PLZPF und der Postfachnummer in der Satzunterart 3

Alternativ könnte ich mir folgende Lösung vorstellen:

• Erweitern der Tabelle alb_g_namen um die in der Übersicht zur strukturierten Namensangabe angegebenen Verschlüsselungsfelder - dem ALKIS Migrationskonzept M-V anpassen
• bei Übernahme der WLDGE-Daten die strukturierten Namensangaben in die entsprechenden Felder einlesen
• unstrukturierte Namensangaben in eine Spalte eintragen, die Satzunterarten durch gewisse Zeichenkombination ev. #1, #2 .. voneinander trennen, um sie in der Druckausgabe dann entsprechend darzustellen
• Anpassen der Druckausgabe für den ALB-Ausdruck nach Fallmerkmal Namensangabe strukturiert oder unstrukturiert

Der momentane Entwicklungsaufwand erscheint mir im 1. Vorschlag geringer. Die 2. Lösung wäre im Hinblick auf ALKIS zukunftsweisender, wobei aber die endgültige Fassung der Migrationsunterlagen noch nicht vorliegen. Damit sind einerseits die endgültigen Felddefinitionen noch nicht bekannt und hinsichtlich des Realisierungszeitraumes könnten Unwägbarkeiten auftreten.

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.