Wunsch-Liste

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

Fachschale Jagdkataster

Die Entwicklung verschiedener Basisfunktionalitäten erfolgt durch den Landkreis Nordvorpommern. Dieser Teil taucht bereits in der ToDo-Liste auf. Weitere Funktionalitäten können/sollen diskutiert werden.

Festpunkte | Einmessungsskizzen im PDF

--Heinz Schmidt 11:01, 12. Jul 2006 (CEST)
Die Einmessungsskizzen der Festpunkte werden für KVWMAP im PNG-Format für die Vorschau und zusätzlich im TIFF-Format für die Archivierung benötigt. Eine Verwaltung anderer Dateiformate wie z.B. PDF oder JPEG wird momentan nicht unterstützt.

Das LAIV stellt den Kreisen im Lande im z. Zt. die TP-Beschreibungen im qualitativ hochwertigen PDF-Dateien zur Verfügung. Diese können in der Form in KVWMAP nicht verarbeitet werden.

Wünschenswert wäre eine Unterstützung variabler Dateiformate durch das System.

Peter Korduan hierzu: "die Aufwendung für die Umstellung auf variable Datentypen schätze ich mit 2 Tagen ein. Machbar sollte es aber sein. Gerade pdf wird ja von den Browsern gut unterstützt. Es ist nur an einigen Stellen im Quellcode einzutragen, dass variable Typen verwendet werden. Die Unterscheidung sollte die Anwendung dann selbständig an Hand der Dateiendungen vornehmen können."

Mailservice

--Markus Hentschel 10:30, 10. Jul 2006 (CEST) Häufig haben Mitarbeiter anderer Fachämter Hinweise zu Daten, die nicht Ihnen gehören (z.B. "Das Gebäude steht dort doch gar nicht mehr" oder "Diese Gaststätte hat den Eigentümer gewechselt"). Das Problem ist: Der Mitarbeiter weiß so etwas, bringt sein Wissen aber nicht zum verantwortlichen Datenherrn, weil "zu aufwändig". Ich könnte mir vorstellen, dass man im Snippet eine Möglichkeit schafft, dem Datenherrn eine Benachrichtigungsmail zu senden. Das geht, wenn auf dem Server der Mailservice aktiviert wurde. Man könnte bei den Daten selber die Mailadresse des entsprechenden verantwortlichen Kollegen speichern. Bei der Sachdatenanzeige kommt ein zusätzlicher Link "Benachrichtigung" o.ä. dazu, der eine kleine Maske zur Eingabe eines Textes öffnet. Als eMail-Empfänger ist die gespeicherte Adresse automatisch eingetragen.

Erweiterung der Druckfunktionalität

--Markus Hentschel 10:08, 10. Jul 2006 (CEST) Die Druckfunktionalität ist jetzt darauf ausgelegt, dass Sie den "amtlichen" ALK-Auszug generieren kann. Für eine allgemeine Druckfunktion ist das vielleicht zu speziell. Es lassen sich einige weitere Funktionalitäten denken:

Legende

Es soll möglich sein, eine Legende im Druckbild zu platzieren. Die Legende soll die im Kartenausschnitt sichtbaren Layer enthalten. Damit die Legende im Kartenbild platzierbar sein kann, muss - wenn nötig - ein entsprechendes Hintergrund-JPG vorhanden sein.

Mehrere freie Texte

Alle festen Bildelemente werden z.Z. im Hintergrund-JPG erzeugt. Das ist von der Qualität her noch nicht optimal. Besser wäre es, wenn alle Texte über die Druckrahmenverwaltung definierbar wären.

Drehwinkel und Norpfeil

Durch Angabe eines Drehwinkels soll das Druckbild gedreht werden können. Dann ist die Anzeige eines Nordpfeils nötig.

Name des PDFs

Das zu druckende bzw. zu speichernde PDF-Dokument soll von kvwmap so benannt werden: <username>-<Datum>.pdf --HolgerR 10:22, 10. Jul 2006 (CEST)

Wasserzeichen

Es soll die Möglichkeit bestehen, bei einem einmal definierten Druckrahmen in Abhängigkeit von der jeweiligen Stelle ein Wasserzeichen quer über das Grafikfester zu hinterlegen, z.B. "INTERN".

Schriftart

Für alle textlichen Elemente sollte es möglich sein, eine Schriftart der fonts.txt auszuwählen.

Kartenmaßstab = Druckmaßstab

--Certa 10:23, 19. Jul 2006 (CEST) Es sollte möglich sein, über einen Extrabutton den Maßstab des dargestellten Kartenausschnittes als Druckmaßstab zu übernehmen. Eventuell sollte der Maßstab auf- oder abgerundet werden. Im Ergebnis sollte das Druckbild dem Kartenausschnitt auf dem Bildschirm entsprechen.

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.

--SigridP 16:22, 28. Jun 2006 (CEST)

ok, da die nutzerabhängige Zuordnung der Druckrahmen nur in wenigen Fällen erforderlich ist, kann man das über zusätzliche Stellen lösen.

Das beschriebene Konzept der Nutzerverwaltung habe ich bisher jedoch nicht so eindeutig gesehen und daher auch nicht konsequent umgesetzt. Über die Tabellen u_rolle2used_layer und u_menue2rolle habe ich innerhalb einer Stelle unterschiedliche nutzerabhängige Zuordnungen vorgenommen (z.B. personenbezogene Notizlayer, Druckrahmenverwaltung für einzelne Nutzer) und bin damit ganz zufrieden. Dieser Aufwand schien mir geringer, als das Anlegen neuer Stellen.

Auch in der kvwmap-Dokumentation heißt es: "Die Rechte der Nutzer in den Stellen werden allgemein durch die Zuordnung der Layer und Menuepunkte geregelt."

Bin ich da auf dem Holzweg???

--HolgerR 16:48, 28. Jun 2006 (CEST)

Durch die gewünschte nutzerabhängige Speicherung der Einstellung in den Layern, Menues & Gruppen (dafür die Tabellen u_rolle2used_layer, u_menue2rolle, u_groups2rolle) trat mit der weiteren Entwicklung von kvwmap der 'Nebeneffekt' auf, innerhalb der Stellen einzelnen Nutzern unterschiedliche Menues und Layer zur Verfügung zu stellen. Vom Ursprung her war das nicht so vorgesehen.

Die Doku kann ja auch so interpretiert werden, dass die Zuordnung in den Stellen 'allgemein' und nicht 'speziell' erfolgt, aber ich glaube, dass ist an dieser Stelle Haarspalterei.

Letztendlich muss jeder für sich entscheiden, wie er das System einrichtet und am besten damit klarkommt.

Vielleicht habe ich ja auch was im Verständis verpasst.

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

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:07, 14. Jul 2006 (CEST)

• 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" (der Link "zurück zur Karte" ist meiner Meinung nach überflüssig).
  • Die zweite Reihe ist dann für die Ausdrucke Format 30, 35 und 40, mit und ohne Wasserzeichen
• 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 $flst->GemeindeID;
  ?>&GemkgID=<?php echo $flst->GemkgSchl; ?>&FlurID=<?php echo $flst->FlurID;
  ?>&FlstID=<?php echo $flst->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'];
  ?>">zur Namensuche</a> |
  <a href="index.php?go=ZoomToFlst&FlurstKennz=<?php echo $flst->FlurstKennz; ?>">Kartenausschnitt</a>
 </td>
</tr> 

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 $flst->FlurstKennz; ?>
         &formnummer=30&wz=0" target="_blank">ALB-Auszug 30</a> |
       <?php } ?>
       <a href="index.php?go=ALB_Anzeige&FlurstKennz=<?php echo $flst->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 $flst->FlurstKennz; ?>
           &formnummer=35&wz=0" target="_blank">ALB-Auszug 35</a>
       <?php } ?>
       | <a href="index.php?go=ALB_Anzeige&FlurstKennz=<?php echo $flst->FlurstKennz; ?>
           &formnummer=35&wz=1" target="_blank">ALB-Auszug 35 mit WZ</a>
     <?php }
     if ($this->Stelle->funktionen['ALB-Auszug 40']['erlaubt']) {
 	    if ($this->Stelle->funktionen['ohneWasserzeichen']['erlaubt']) { ?>
 	    | <a href="index.php?go=ALB_Anzeige&FlurstKennz=<?php echo $this->flst[$i]->FlurstKennz; ?>
               &formnummer=40&wz=1" target="_blank">ALB-Auszug 40</a>
       <?php } ?>
       | <a href="index.php?go=ALB_Anzeige&FlurstKennz=<?php echo $this->flst[$i]->FlurstKennz; ?>
           &formnummer=40&wz=0" target="_blank">ALB-Auszug 40 mit WZ</a>
       <?php } ?>
 </td>
</tr> 

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 ein User auch von mehreren Stellen sehen, bearbeiten, löschen kann, ohne das er extra die Stelle wechseln muß,
  • 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.