Bei SubForm-Layern muss das Import-Formular in der Sachdatenanzeige eingebettet angezeigt werden.

Einladungen die über die Einladefunktion angelegt werden, sollen für alle in Adminstelle sichtbar sein.
(wenn möglich filterbar)

--> so umsetzen für Admin

Der Wunsch besteht, dass bei der Streckenmessung nachvollziehbar ist, wo mit der Strecke begonnen und wo geendet wurde. Möglicherweise sollten die Knickpunkte auch hochzählend nummeriert werden?

--> so umsetzen

Sinnvoll wäre es auch die Richtung der Linien im Linieneditor anzuzeigen. Es gibt hier das Werkzeug "Linienrichtung umkehren" hat so aber keinen Sinn, wenn man die Richtung nicht kennt, oder?
H.S. 2022-10-27

Für die maßstabsabhängige Gestaltung von Beschriftungen werden die Felder Minscaledenom und Maxscaledenom, ähnlich wie beim Style, gewünscht.

--> überprüfen ob es es "text" in label gibt?

Wenn in der Konfiguration AEQUIVALENZ_BEWERTUNG auf false gestellt ist, wird die Verschneidung mit der Bodenschätzung durchgeführt, um die Ertragsmesszahlen zu ermitteln. Das passiert bei allen Flächen, wo es ein AX_Bewertung-Objekt gibt. Leider ist es wohl so, dass AX_Bewertung-Objekte auch mal abhanden kommen können. Das bedeutet, dass dort, wo keine AX_Bewertung-Objekte sind, immer auch noch geprüft werden muss, ob es beim Flurstück nicht doch eine landwirtschaftlich genutzte Fläche gibt. In diesem Fall ist dann eine Äquivalenzbewertung durchzuführen.

--> wird so gemacht, Parameter "AEQUIVALENZ_BEWERTUNG" kann weg

In den Optionen werden die Themenparameter aufgelistet. Das können durchaus viele sein und oft heißen sie gleich ("Jahrgang", "Styling", ...). Hilfreich wäre die Nennung des jeweiligen Themennamens.

--> Namen des Themas in der globalen Parameterliste mit anzeigen.-

Wenn DELETE_ROLLENLAYER auf 'false' gestellt ist, werden es immer mehr gespeicherte Suchanfragen beim Nutzer, die bei jeder Kartenaktion durchgeführt werden. Die Mehrzahl der Suchergebnisse wird nie wieder benötigt und verursacht eine ziemliche Last. Wir haben mittlerweile mehrere Zehntausend (!) gespeicherte Suchanfragen. Die Anwendung geht langsam aber sicher in die Knie. Trotzdem benötigen einige Nutzer diese Funktionalität.

Gespeicherte Suchergebnisse müssen grundsätzlich beim Logout gelöscht werden. Für das Speichern von Suchergebnissen muss ein anderer Weg gefunden werden.

Der Nutzer muss (beim Suchergebnis?) auswählen können, ob er das Suchergebnis über das Logout hinaus benötigt. Vielleicht sollte auch nicht das Suchergebnis, sondern lediglich die Suche gespeichert werden. Oder das Suchergebnis wird in der Postgres in etwas ähnliches wie custom _shapes gespeichert.

--> Rollenlayer werden generell gelöscht, es sei denn es wird über die Layeroptionen verhindert. DELETE_ROLLENLAYER kann weg!

Ein Nutzer wurde archiviert, dann aber zu einem späteren Zeitpunkt in einem anderen Zusammenhang in einer anderen Stelle vermeintlich neu angelegt. Es kommt ein Hinweis, dass es den Nutzer schon gibt, ohne dass man ihn in der Nutzerliste findet. Besser wäre ein Hinweis, dass es den Nutzer als archivierten Nutzer gibt. Eventuell kann man ihn hier gleich reaktivieren.

--> umsetzen, Hinweis erweiteren und archivivierte Nutzer wahlweise anzeigen

Bei der Digitalisierung muss häufig dicht ran- und dann wieder weit rausgezoomt werden. Das ist zeitaufwändig und nervenaufreibend. Vorstellbar ist ein Extrafenster, das den Bereich des Cursors sehr stark vergrößert zeigt. Eventuell kann man sogar in diesem Extrafenster zoomen. Es müsste diskutiert werden, ob der Punktfang in der gesamten Karte oder nur im Extrafenster aktiviert wird.

--> ausprobieren über SVG-Zoomen

Wenn in der Suchergebnisliste nur noch ein Eintrag übrig ist, sollte die Suche mit Enter abgeschlossen werden können und das Kartenfenster zentriert sich auf diesen Ort.

--> umsetzen 

Das Einloggen mit einer Nutzerkennung sollte nicht zeitgleich mehrfach möglich sein. Zum einen ist das ein Sicherheitsfeature und zum anderen werden (aus Amtsverwaltungen) "Container-Accounts" gewünscht, also z.B. ein Azubi-Account.

--> umsetzen, Absturz berücksichtigen, Datenschutz ?

Übersteigt die Anzahl der Treffer die maximal angezeigten Treffer pro Seite, ist die Funktion "alles auswählen" irreführend. Denn es werden effektiv nur die Treffer aus der angezeigten Seite ausgewählt, nicht aber alle weiteren Treffer aus den folgenden Seiten der Trefferliste.
Deshalb entweder die Bezeichnung ändern oder eine weitere Funktion "alles auf dieser Seite auswählen" hinzufügen. 

--> Umbenennung in "alle Angezeigten auswählen" (Anzahl anzeigen), 
2. Link "alle Gefundenen auswählen" (Anzahl anzeigen)

Es wurde gewünscht, dass es eine Funktionalität gibt, die alle Objekte eines Themas mit einem Puffer versieht, der auswählbar ist. Die Anzeige in der Karte ähnlich wie die Strecken- oder Flächenmessung nur temporär im Client.

--> Umsetzen bei Rollenlayern direkt und bei normalen Layern entsteht ein gepufferter Rollenlayer, über die Layeroptionen. Layeroptionen von neuen Rollenlayern sofort anzeigen.

Bei einem über Layer-Suche_Suchen aufgerufenen Suchergebnis kann man einen Parameter &opentab= angeben, der den entsprechenden Tab aufklappt.

Denkbar wäre die generelle Abschaltung der Tooltips für eine Rolle. Könnte man ja bei den Einstellungen unterbringen.

Beim Werkzeug Anderes Objekt Bearbeiten wäre es gut, wenn man auch dort die Tooltip Funktion nutzen könnte. Es kann manchmal passieren, dass viel Datensätze nahe eines Punktes sitzen (Haltestellenkataster).

Wäre es möglich die Themenparameter eines Layer auch in der Sachdatenanzeige unterzubringen? Vielleicht in der Überschrift des Layers oder das Attribut selbst in der Sachdatenanzeige.

Nur die Parameter die in der Query benutzt werden, werden oben in der Sachdatenanzeige zum ändern angeboten.

Es wäre gut, wenn man alle Datensätze direkt aus dem Subform Embedded löschen könnte.

Über neuen Button.

Es wäre gut, wenn man Bilder durch ein Dropdown Menü auswählen könnte. Es wäre die Kombination aus zwei Feldtypen in kvwmap. Wunsch entstand durch Schilderkataster.

Neuer Formularelementtyp "Auswahlfeld mit Bildern": Im output steht der komplette Bildpfad.

Beim Nutzerdaten-Editor wäre es besser, wenn unter berechtigte Stellen auch die abgelaufenen Stellen angezeigt werden. Zur Unterscheidung könnten diese dann in grauer Schrift dargestellt werden.

Allgemein: Möglichkeit, die Suchparameter bei der Adress-, Flurstücks- und Eigentümersuche zu speichern und später wieder aufzurufen.

Eigentümersuche: Die Auswahl der angehakten Checkboxen in der Trefferliste nach einer Suche muss erhalten bleiben, auch wenn der Nutzer die Trefferliste sortiert.

Beim Aufruf des Menüpunktes SHP_Import Parameter für:
  - Schema
  - Tabelle
  - Optionen (neu | überschreiben | anfügen)
übergeben.
Die Felder sind somit vorausgefüllt und die Fehleranfälligkeit ist geringer.

Anderen Weg über layerspezifischen Daten-Import: Aufrufbar über Layeroptionen. Evtl. mit Häkchenfeld "vorhandene Daten vorher löschen". Nur für Nutzer mit dem Recht Layerdaten zu importieren.

Für n_nutzung und lk_nutzungen wird eine Erweiterung um datumderletztenueberpruefung und herkunft_source_source_ax_datenerhebung gewünscht. In lk_nutzungen könnte herkunft_source_source_ax_datenerhebung in art_der_datenerhebung umbenannt werden.

Viele custom_shapes-Tabellen sind ganz offensichtlich nicht mehr im Einsatz und blähen nur die Datenbank auf. Kann man sie zuverlässig überprüfen und gegebenenfalls löschen? Wäre ein Ansatz, den Tabellen im Namen noch den Zeitstempel der Entstehung zu verpassen?

Im Tabellennamen die zufällige Zahl durch einen Zeitstempel ersetzen.

Implementierung der Anwendungsschemata GeoInfoDok 7.1 und Anpassung der Datenbankabfragen (geplante Einführung in ALKIS: Hrbst 2023)

Testdaten?

Mapserver bietet den sog. LEADER Block an. Damit kann Mapserver Zuordnungslinien bei Beschriftungen zeichnen und diese so neben das Objekt stellen, falls die Beschriftung mit anderen Beschriftungen kollidiert.

Beim Style- und Labeleditor im Label unterbringen als extra Block "Zuordnungslinie" mit 3 Parametern: Maxdistance, Width und Color

als Link in der Flurstücksanzeige

mit Sternchen 

Für das erstellen und gestalten von Tabellenstrukturen in kvwmap, wäre es schön, wenn man die Breite einer Spalte definieren und mehreren Attributen eine zusammenfassende Beschriftung geben könnte.

Überprüfen ob Spaltenbreiten automatisch besser dargestellt werden können. Beispiel in MSE Layer Wildnachweisung.
Im Attributeditor neues Feld für die Breite mit Werten wie 50px oder 50%.

Zur besseren Identifizierung der Datensätze bei der Verwendung von Tabs wäre es wünschenswert, wenn aus den vorhandenen Attributen eine Datensatzkennung im Header des jeweiligen Datensatzes angezeigt werden kann.

Neues Feld im Layer, in dem man ähnlich wie bei der Subform-Definition beliebigen Text und Attribute eintragen kann. Das erscheint dann im Datensatz-Header.

Die Legendenoptionen sollen auch in den Masken der Nachweisverwaltung erscheinen, in denen die Legende zur Verfügung steht.

Wenn man in der Flurstücksanzeige den CSV-Export aufruft, kann man von dort aus auch wieder zurück. Bei großen Mengen an gesuchten Flurstücken dauert das zurück noch mal so lange wie das ursprüngliche Suchen. Könnte der CSV-Export in einem separaten div oder separaten Browser-Fenster aufgerufen werden, so dass man das Suchergebnis nicht verliert?

In darüberliegendem div anzeigen.

Beim Versuch, eine vorhandene oder eine neue flächenhafte Geometrie über "Polygone teilen" zu zerlegen, kommt eine Self-Intersection-Fehlermeldung, die darauf hinweisen soll, dass diese Geometrie noch nicht valide ist und bearbeitet werden muss.
Um den Nutzer nicht mit englischen Fehlermeldungen zu quälen (er hat ja nichts falsch gemacht), könnte kvwmap entweder beim Teilen schon für eine minimale Lücke sorgen oder dem Nutzer eine zielführende Meldung geben, dass er jetzt noch was zu tun hat.

Nach dem Teilen keine Geometrieprüfung durchführen, sondern folgenden Text ausgeben:

"Teilung erfolgreich. Zum Abspeichern Schnittlinie bearbeiten oder in neue Objekte aufteilen."

Bei sehr großen Mengen von Flurstücken funktionieren Flurstücks- und Eigentümer-CSV-Export irgendwann nicht mehr. Dennoch wird beides auch bei großen Mengen in der Katasterauskunft benötigt. Es braucht eine Lösung, wie die Flurstücke ausgegeben werden, ohne dass der Nutzer gezwungen wird, seine Flurstücksliste in mehrere Happen aufzuteilen.

hat sich erledigt

Es gibt nur noch *eine* Flurstückssuche. Wird eine historische Gemarkung und/ oder eine historische Flur ausgewählt, erscheinen nur die historischen Flurstücke. Wird in einer aktuellen Flur gesucht, werden sowohl aktuelle als auch historische Flurstücke angeboten.
3 Radiobuttons: 
"nur aktuelle Fluren/Flurstücke"
"nur historische Fluren/Flurstücke"
"aktuelle und historische", die standardmäßig auf aktuell stehen.
Wird eine historische Gemarkung/Flur ausgewählt, springen die Radiobuttons auf "nur historische Fluren/Flurstücke" und werden inaktiv.

Bei den internen Auszügen "Flurstücksdaten mit Eigentümer" und "Eigentümerdaten zum Flurstück":

- Bei Güter- sowie Erbengemeinschaften könnte so wie in der Sachdatenanzeige ein vertikaler Strich zur Verdeutlichung hinzukommen (bei verschachtelten Beziehungen ist die Darstellung besonders schlecht...)

- Bei mehreren Beständen: Der Abstand von einer "Bestand"-Zeile zur ersten Datenzeile ist wesentlich größer als der Abstand von der letzten Datenzeile zur nächsten "Bestand"-Zeile. Anders herum macht es Sinn.

- Bei Aufteilungsplan zu Wohnungs-/Teileigentum fehlt der entsprechende Hinweistext ("verbunden mit Sondereigentum..."). 

Wenn im Labelitem was falsches steht, wird der Layer ohne jeden Hinweis einfach nicht gezeichnet. Es wäre schön, wenn kvwmap beim Speichern der Layerdefinition prüfen würde, ob es den angegebenen Labelitem überhaupt gibt.

Fehlermeldungen vom Mapserver wieder anzeigen.

Im Moment ist es nur möglich die Geometrie bei Linien und Polygonlayern von vorhanden Geometrien zu übernehmen. In der Auswahlliste werden aber jeweils alle Layer (Linien, Polygone, Punkte und Layer ohne Geometrie) angeboten. Hier wäre es gut, wenn auch nur die Layer angeboten werden würden, deren Geometrietyp auch übernommen werden kann. 

Verwendet die noch jemand?

Kann weg

Es sollte möglich sein, Tabs auch ohne die Angabe von Gruppen zu definieren. Dabei sollte man innerhalb eines Layers Tabs ohne und Tabs mit Gruppierung anlegen können.

Wenn nur eine Gruppe im Tab angezeigt wird und der Gruppenname dem Tabnamen entspricht, wird der Gruppenname nicht angezeigt.

Gewünscht wird, dass im Übergabeprotokoll, in der Uebersicht.csv und in der Uebersicht.htm der geprüft-Status in einer weiteren Spalte erscheint.

Aus dem Kreis der B-Planserver-Nutzer wird gewünscht, dass man Objekte, die in kvwmap als Array in der Datenbank gespeichert sind sortieren könnte.
Es gibt Nutzer, die gerne Einfluss auf die Reihenfolge der angehängten Dokumente von Pänen nehmen möchten. Die sind als Array definiert.
Die Reihenfolge in der die Dokumente aufgelistet werden, soll definierbar/veränderbar sein. siehe Ticket https://geo.sv.rostock.de/redmine/issues/2987

Bei den Array-Elementen mit Pfeilen umsetzen.

Die Headerzeile im Übergabeprotokoll sollte zur besseren Unterscheidbarkeit grau hinterlegt werden. Dazu ist PDFClass mit mind. Version 0.12.9 nötig, neueste ist 0.12.63

Geometriefenster als Reiter und die Sachdaten auch als Reiter. Also lauter Reiter. Dann braucht man nicht mehr scrollen.

Es wäre schön wenn der Nutzer die Breite der Legende selbst einstellen kann. Das ist notwendig wenn die Layerbäume länger werden mit mehreren Gruppen z.B.

Wunsch von Herrn Bimüller LK-EE

Es wäre schön wenn es noch mehr Eigenschaften in der Layeranzeige gäbe, z.B. Geometrietyp oder Postgis / WMS oder WFS.

Und die ganze Zeile als Link machen.

ID reverse (absteigend) sortierbar machen.

In der spaltenweisen Darstellung wir eine Möglichkeit gewünscht, mit der Spalten dauerhaft ausgeblendet und auch wieder eingeblendet werden können. 

In allen Darstellungen als rollenbezogene Sichtbarkeit über Auswahlfeld mit Häkchen umsetzen.

Auch bei Hatch-Styles muss es möglich sein, im Style-Editor die Farbe über ein Attribut anzugeben.

Scheint wohl nicht zu gehen. Der Mapserver liefert dann immer: preloadSymbol(): General error message. unsupported symbol type 1005

Verwendung von Layer-Parametern auch in Alias, Erläuterungen und Gruppe.

Wird auf einem Sachdatendruck ein Kartenausschnitt dargestellt, werden dort diejenigen Layer dargestellt, die aktuell aktiviert sind.
Besser wäre es, wenn ein Standard definiert werden könnte (z.B. immer OSM als Background und nur ein oder zwei Layer, idealerweise auch mit definierter Beschriftung und Transparenz).
Eventuell ließe sich das über die Auswahl einer gespeicherten Themenauswahl im Druckeditor lösen?

Bei der Definition der Layer-Parameter sollten auch dynamische Standardwerte, sprich: SELECTs möglich sein. Die Angabe von statischen Werten muss natürlich weiter möglich sein.

Erweitern der Flurstücksanzeige um die Antragsnummer.
Die Kollegen haben gleich im Blick, mit welchem Antrag das Flurstück entstanden oder fortgeführt wurde.
Die Antragsnummer kann über zeigtaufexternes_art und zeigtaufexternes_uri aus AA_Antrag abgeleitet werden. 

Bei der Nutzung der Einladungsfunktion wäre es von Vorteil, wenn man den Benutzernamen interaktiv vorgeben könnte. Aktuell wird eine Kombination aus dem ersten Buchstaben des Vornamens und dem Nachnamen angeboten.

Neben der Funktion "Polygon zeichnen" wäre es wünschenswert, wenn es direkt die Möglichkeit gibt Linienobjekte zu zeichnen.
Aktuell lassen sich mehrere von einander getrennte Linienobjekte nur zeichnen, wenn die Funktion "Polygon zeichnen" nach 2 Punkten beendet wird.

Für das temporäre Anzeigen von Layern in einer vorgegebenen Klassifizierung besteht der Wunsch, zu den Importlayern einen Style im SLD und/oder QML-Format zu laden.

In der Rechtevergabe zu den Layern steht bei den untergeordneten Stellen - Rechte von Elternstelle übernehmen - Hilfreich wäre es, wenn auch gleich sichtbar ist, wer die Elternstelle ist.

Es wäre hilfreich, wenn im Suchergebnis abgeleitete Werte, wie 
- der Flächeninhalt, 
- die Umringslänge,
- die Länge bei Linien
- die Lagekoordinate bei Punkten
automatisch angezeigt werden.

Die momentane Situation ist ja so, dass die Tooltips nur für den Layer angezeigt, der in der Darstellungsreihenfolge ganz oben steht.
Es würde doch sinnvoll, wenn im Layer-Optionsmenü der Tooltip für die einzelnen Layer an- bzw. ausgeschaltet wird. Der Nutzer hat dadurch die Möglichkeit, gezielt den Lyer auszusuchen, für den der Tooltip angezeigt werden soll.

Das Fenster für den Tooltip ist immer sehr dicht am Mauszeiger platziert. Es ist mitunter recht schwierig, die Informationsabfrage für das gewünschte Objekt auszuführen. Kann das Tooltipfenster nicht 4-5 Pixel vom Mauszeiger weg platziert werden?

Wenn im Tooltip Eigentümerangaben angezeigt werden, sollten diese Zugriffe auch gelogt werden.

Punkt 3 generisch als log_consume Tabelle für jede Sachdatenanzeige mit den als zu loggenden Attributen umsetzen. 

Nicht ASCII-Dateien verursachen Fehler wenn sie in der Flurstückssuche unter Flurstücksliste importiert eingelesen werden.
Es sollten nur die Dateitypen geladen werden, die auch unterstützt werden.

Ähnlich wie bei der Nachweisrecherche wäre ein Löschsymbol zum Entfernen aller eingegebenen Suchparameter hilfreich.
Durch eingeklappte Gruppen im Suchformular sind nicht alle Suchparameter auf einem Blick sichtbar. Wenn ein Parameter übersehen wird, kann es zu Fehlinterpretationen kommen.

Kann beim Aufruf des letzten Suchparameters wirklich das letzte Formular angezeigt werden, für das die Eingaben vorgenommen worden sind? 
Momentan ist es so, dass bei verknüpften Themen, das letzte angezeigte Thema als letztes Suchparameter angeboten wird.

Bei Punkt- und Linienlayern sollte die Stufe "Nur Umring darstellen" entfallen.

Für einige Layer wäre es gut, die Sizeunit setzen zu können (z.B. für Punktobjekte, die einen bestimmten Radius in Metern haben sollen)

Gewünscht wird, dass in der Legende des Kartendrucks auch die Import- und Suchergebnis-Themen aufgelistet werden, soweit sie in der Legende "an" sind und Objekte im Druckbereich liefern.

Gewünscht wird, dass Texte in der Klasse und im Label erzeugt werden können.

Überprüfen ob man Attributnamen im Feld Text der Klasse bzw. im Feld ??? des Labels verwenden kann um sozusagen verschiedene Labelitems zu verwenden.

Was kann man möglicherweise tun gegen "Dokument erloschen"?

Wir gucken mal, was da geht.

Es wird gewünscht, dass man in der Trefferliste die Möglichkeit hat, die Dokumente einer angezeigten Messung (die ja nicht vollständig in der Trefferliste vorhanden sein muss) per Klick zu vervollständigen. Im Ergebnis sollte ide Trefferliste also um die fehlenden Dokumente dieser konkreten Messung ergänzt werden.

Im Attributeditor soll es einen neuen Formularelementtyp geben: das Farbauswahlfeld. Ordnet man dieses einem Attribut zu, wird als output ein Farbauswahlfeld angezeigt. Als Value wird der RGB-Code in der Form 125 254 10 zurückgegeben. Das Attribut kann dann bei der Zurdnung zuneiner Klasse verwendet werden. 

Als Auswahlfeld mit den Farben aus der Tabelle colors.

In der Layerdefinition soll man festlegen können, das in der Legende nur Klassen angezeigt werden, für die auch Inhalte vorhanden sind.

Evtl. aus Mapobjekt ermittelbar? Nur umsetzen, wenn es performant ist.

Es wird eine zusätzliche Zeile direkt unterhalb des Titels - "Liste der ausgegebenen Unterlagen" benötigt.
Inhalt der Zeile kann entweder in den config-Parametern vergeben werden oder fest im Programmcode von kvwmap eingefügt werden. 

Als config-Parameter.

Gesucht wird eine Art Wasserzeichen das über den Layer gelegt werden kann. Der Nutzer könnte damit z.B. auf Nutzungsbedingungen des Layers hingewiesen werden.
Über einen zusätzlichen WMS-Layer und "Requires" auf den betroffenen Layer funktioniert dies bereits, ist aber umständlich weil zu jedem Layer ein WMS und ein Layer erstellt werden müsste.
Kann ein Wasserzeichen auch direkt über die Layereinstellung des gleichen Layers realisiert werden?

Für jeden Layer kann man einen abhängigen Layer definieren. Dies entweder umsetzen über mehrere Layer in requires oder ein neues Layer-Feld "abhängiger Layer".

Die Anzahl der in einer SubformPK aufgelisteten Datensätze soll im Alias der betreffenden Spalte oder auch ggf. in der Gruppenbezeichnung mit ausgegeben werden können. Vorschlag: Es wird zu jeder SubformPK automatisch eine Variable generiert. Die Bezeichnung dieser Variable setzt sich zusammen aus der Spaltenbezeichnung und dem Zusatz _count. Der Wert der Variable entspricht der Anzahl der in der SubformPK angezeigten Datensätze. Diese Variable kann dann beliebig im Alias einer Spalte oder in der Gruppenbezeichnung verwendet werden.

Anzahl über der Subformliste ausgeben: "23 Datensätze". Das Ganze aber konfigurierbar im Attributeditor im Optionenfeld des SubformEmbeddedPK-Attributs.

Bei Geometrien mit sehr vielen Knickpunkten wird die Bearbeitung unter Umständen sehr langsam und damit praktisch unmöglich, z.B. bei einem einfachen Verschieben von einem Knickunkt. Nötig wäre vielleicht, die Art und Weise zu überdenken, wie der Geometrieeditor solche Geometrien bei bestimmten Operationen behandelt.

Bei Markus nachfragen.

Bei Datums-Feldern sollte kvwmap folgende Schreibweisen "übersetzen":
- "1.4."   ->  01.04. aktuelles Jahr
- "1.4.20" ->  01.04.2020

Bei Time-Feldern (also nur Uhrzeit) sollte kvwmap folgende Schreibweisen "übersetzen":
- "9.30"  ->  09:30
- "14"    ->  14:00

Bei anderen Schreibweisen sollte kvwmap die SQL-Fehlermeldung abfangen und in was Ordentliches übersetzen.

In den Optionen sollte einstellbar sein, ob der Nutzer nur hh:mm oder auch hh:mm:ss eingeben soll/muss.

Datum geht schon. Bei der Uhrzeit Punkt in Doppelpunkt umwandeln und fehlende Angaben mit 00 auffüllen.

Wenn der Nutzer einen Datensatz aus einem Layer sucht und löscht, der per SubformPK an einen übergeordneten Layer gebunden ist, dann landet er nach erfolgreichem Löschen in der Karte mit einer Meldung „Zu diesem Thema wurden keine Objekte gefunden!“. Der Nutzer kann mit der Meldung wenig anfangen, gefühlt wird er in diesem Moment etwas allein gelassen.

Wäre es nicht besser, wenn er in so einem Fall zum verknüpften Datensatz aus dem übergeordneten Layer geführt wird? Dann ist er noch in der "richtigen" Umgebung und kann z.B. sofort wieder einen neuen Datensatz anlegen (oder auch weitere löschen).

Den einzelnen übergeordneten Datensatz anzeigen.

Es wäre wünschenswert in der Anzeige "Stellendaten" eine Hierarchie sehen zu können.
Übergeordnete Stellen sollten optisch hervorgehoben werden und eine Zuordnung der untergeordneten Stellen sollte erkennbar sein. 

In der Stellenliste eine neue Spalte Elternstellen hinzufügen, nach der auch sortiert werden kann.

Evtl. kompletten Stellenbaum darstellen.

Beim Zoom auf ein Punktobjekt und beim Datenimport von punktförmigen Objekten wird derselbe Style verwendet. Wünschenswert wären zwei verschiedene, konfigurierbare Styles.

Neuer config-Parameter ZOOM2IMPORTPOINT_STYLE_ID. Wenn ZOOM2POINT_STYLE_ID einen Wert hat, wird dieser per Migration auch in ZOOM2IMPORTPOINT_STYLE_ID eingetragen.

Das separate Browserfenster bei einer Sachdatenabfrage sollte einen (konfigurierbaren) eigenen Title bekommen können.

Keinen konfigurierbaren Title, sondern den Title aus den abgefragten Layernamen zusammensetzen.

Layerbaum - ist für einen Layer ein Link vergeben, wird dieser beim Klicken des Layer-Eintrages geöffnet. Das ist nicht offensichtlich. Besser wäre ein zusätzlicher Button oder zu mindestens ein ToolTip (Title HTMLElement = extern: Link)

Link in die Layer-Optionen packen.

In der Messungsvorbereitung werden in der Regel nicht alle Treffer der Trefferliste in das zip-Archiv übernommen. Es werden Häkchen entfernt. Diese Arbeit dauert und kann unterbrochen werden. Dabei ist die Auswahl im schlimmsten Fall verloren. Gewünscht wird ein (automatisches?) Speichern der Häkchenauswahl.

Häkchenauswahl bei jeder Änderung automatisch speichern. Bei Aufruf von "go=Nachweisanzeige" und zusätzlichem Parameter "auswahl=1" wird Häkchenauswahl geladen.

Wunsch der Messungs-Vorbereitung: Die Trefferliste der Nachweisrecherche sollte ein schwebendes Fenster analog zur Sachdatenanzeige werden. Riesiger Vorteil: Das Fenster kann auf einen zweiten Bildschirm verschoben werden, der Nutzer kann Trefferliste und Karte gleichzeitig betrachten. Das Highlighting der Geltungsbereiche in der Karte beim Hovern der Zeilen der Trefferliste wird gewünscht (die kleine Zusatzkarte muss bleiben!)

Funktion im Client, die von der aktuell bearbeiteter Geometrie alle Teile abschneidet, die von anderen Flächen des gleichen Layers räumlich überschnitten werden.

Als Werkzeug "Überlappungen entfernen" in die Werkzeugleiste aufnehmen.

KML-Import wird bereits unterstützt. Gebräuchlicher ist jedoch die gezippte Version KMZ. Gelegentlich wird durch Unternehmen/Bürger ein KMZ abgeliefert, dass sehr einfach durch das weitverbreitete GEarth erstellt werden kann. Für den Import ist wohl die libkmkl-Bib notwendig: https://gdal.org/drivers/vector/libkml.html#vector-libkml. Ersatzweise könnte auch in einem Workflow das KMZ beim Import unzipped und das enthaltene KML importiert werden.

Wenns einfach umzusetzen ist, dann umsetzen. Ansonsten nicht.

Idee 1:
SubformPK und SubformEmbeddedPK (no_new_window) könnten in der schwebenden Anzeige anders als bisher immer im gleichen Fenster besser in einzelnen, separaten Fenstern angezeigt werden, wobei das Eltern-Fenster jeweils stehen bleibt. Das Eltern-Fenster ist solange inaktiv, bis das Child-Fenster wieder geschlossen wurde. (Sinn macht das aber nur, wenn alle Browserfenster gleichzeitig aus der Statuszeile hochgeholt werden, egal welches man anklickt)

Idee 2:
Gruppen oder 1:1 Verbindungen könnten alternativ zur bisherigen Darstellungsweise als Tabs konzipiert werden (also ähnlich wie Optionen-Seite). 1:1 Verbindungen sind 2 oder mehr Layer auf derselben Tabelle mit Verknüpfung durch dynamischen Links.

Idee 1: Ja, aber rollenbezogen in Optionen aktivierbar.

Idee 2: Ja.

Geometrie soll übernommen werden.

Neben dem Export der Layerdefinition sollte es auch möglich sein, Karten- und Sachdatendrucklayouts zu exportieren?

Machen wa

Neben den kompletten Löschen eines Benutzers über die Benutzer-Stellen-Übersicht (Neues Feature in der 3.0) sollte es auch die Möglichkeit geben, den Benutzer nur aus der Stelle zu entfernen.

Button umwandeln in "Benutzer aus Stelle entfernen"

Seitdem sich nach Apple nun auch Microsoft und Google mit dem HEIF-Format beschäftigen, wäre zu überlegen, ob auch kvwmap in der Lage sein sollte, solche Dateien darzustellen (als Foto oder auch als Video, je nachdem).

Stefan verschafft sich einen Überblick und baut es ein, wenn es geht

Es kam der Wunsch, dass der Nutzer die Parameter des Datenxports (Format, CRS, Attribute, Gruppennamen, Auswahlpolygon und Polygonparameter) speichern kann. Beim Aufrufen müsste kvwmap die Attribute daraufhin überprüfen, ob es sie noch gibt.

Mehrere Export-Einstellungen speichern. Das pro Layer und Rolle

In geometrielosen Layern würde es sich gut machen, wenn man direkt im Suchergebnis einen neuen Datensatz hinzufügen könnte, also einen reinen Sachdatensatz. Beispiel: Geometrieloser Layer für die Angabe von Straßen-Zustandsabschnitten mit bestimmten Eigenschaften, die dann über Lineare Referenzierung auf Straßen-Knotenabschnitte projiziert werden. Bislang kann man im Suchergebnis bestehende Daten ändern, muss aber zum Hinzufügen neuer Datensätze über "Neuer Datensatz" gehen.

So umsetzen, auch für Geometrie-Layer, bei denen auch Datensätze ohne Geometrie angelegt werden dürfen. Für beide Darstellungsvarianten

Der Zugriff auf die personenbezogenen Daten des Liegenschaftskatasters wird geloggt, nicht jedoch der Zugriff auf andere Datenbestände, die personenbezogenen Daten aufweisen. In u_consume könnte eine weitere activity "getData" oder so ähnlich hinzukommen.

Mach so

Der Wunsch ist, als Nutzer alternativ zur Angabe des Druckmaßstabs einen Maßstabsbalken im PDF-Kartenausdruck auswählen zu können.

Zurückgestellt. Noch mal konkretisieren

Wenn man eine Linienbreite dezimal mit Nachkommastellen angeben will ("0,25"), dann muss man einen Punkt als Dezimaltrenner verwenden. Für die Nutzer wäre das Komma nutzerfreundlicher.

Punkt-Eingabe wird in Komma verwandelt. Überprüfung, ob irgendwo anders ebenfalls noch der Punkt regiert

Mittlerweile gibt es (in VR) 4 Pull Downs im Header: ALKIS-Sicht, Adresssuche, Themenparameter und Avatar. Wenn man sie öffnet, bleiben Sie stehen und überdecken sich dabei zum Teil. Es müsste mindestens dafür gesorgt werden, dass sich das erste geöffnete Fenster schließt, wenn ein 2. geöffnet wird. Dieser Mechanismus muss zudem publik und nachnutzbar sein, damit mögliche zusätzliche, eigene im Header verbaute Pulldowns am Mechanismus teilhaben können.

Hau rein

Es wäre schön, wenn nach Abschluss einer Flächenmessung mit dem Kombiwerkzeug der gemessene Flächeninhalt zunächst stehen bleiben würde, ebenso wie die Umgrenzung selbst. Auch bei einer Längenmessung sollte die Gesamtlänge stehen bleiben. Beides möglichst so, dass man den Wert markieren und in die Zwischenablage kopieren kann.

Das Feld, welches für die Koordinatenabfrage verwendet wird, nutzen und dort die Fläche bzw. Gesamtlänge eintragen.

Praktisch wäre, wenn man Geometrie übernehmbar schon als Default-Wert in die Stellen-Zuweisung festlegen könnte!

Manchmal möchte man einfach einen kompletten Layer kopieren (ohne Export o.ä.). Die Funktion "Als neuen Layer speichern" löscht jedoch die Eintragungen der Attributtabelle. 

Hierfür sollte es eine neue Schaltfläche "Layer kopieren" geben, die auch diese Eintragungen übernimmt.

"Layer kopieren" in der Layerliste mit Eingabe von Layer-ID und Name.

Das Vorschaubild für den Geltungsbereich sollte größer oder individuell einstellbar sein.

Bisher werden die Themenparameter ausschließlich in einem speziellen Menü angeboten. Besser zu handhaben wäre der Themenparameter im Layermenü. Es würden dann dort nur die Parameter für diesen Layer angeboten. Wird der Themenparameter verändert, wird der Layer neu geladen. Dann müsste man auch nicht mehr zusätzlich den "Neu Laden" - Button benutzen.

Globale Layerparameter (also die, die von mehreren Layern verwendet werden) werden wie gehabt oben bei den Themenparametern angezeigt. Layerparameter, die nur von einem Layer verwendet werden, tauchen dort wiederum nicht auf, sondern nur in den jeweiligen Layeroptionen.
Evtl. den Layeroptionsbutton in einer anderen Farbe, damit man sieht, dass man dort was ändern kann.

Für die Kommunikation mit der PostgreSQL-Datenbank wird die Unterstützung von Großbuchstaben in der Query- und dem Datastatement sowie in der Haupttabelle und Schema gewünscht

Aktuell kann ich in kvwmap einen Wert definieren, der dann für alle Layer gültig ist. Bei einigen Layern wäre es sinnvoll, davon abzuweichen. So zum Beispiel beim Jagdkataster. Der zentrale Layer (JB-Info) ist so voll gepackt mit Subforms, das die Anzeige von 25 Datensätzen nicht sinnvoll ist. Hier wäre die Anzeige von 5 Datensätzen pro Seite günstiger. Eine diesbezügliche Einstellung bei der Layerdefinition fände ich sinnvoll. Wird sie nicht vorgenommen, gilt der Standardwert aus dem Admin-Bereich.

Es wäre von Vorteil, wenn beim Sachdatendruck ein in seiner Größe frei definierbarer Kopf- und/oder Fußzeilenbereich eingestellt werden könnte. So könnte ein Überschreiben von in der Druckvorlage vorhandenen Grafiken usw. verhindert werden.

Das geht schon über die Rändern. Aber die Grenze des oberen und unteren Randes als gestrichelte dünne Linien anzeigen.

Hallo Stefan,

nutzt außer uns eigentlich jemand das PlugIn ProBaug-Bausauskunftsuche?

Mir ist jetzt aufgefallen, dass die Auswahl in den Feldern Verfahrensart und Vorhaben in der Bauauskunftsuche veraltet sind und in weiten Teilen nicht mehr zu den Daten passen.

Es gibt dort mittlerweile deutlich mehr Merkmale und auch Änderungen der Bezeichnung, vermutlich durch zwischenzeitliche Gesetzes/Verfahrensänderungen, sicher auch intern in ProBaug eingefügte Kategorien und damit Migrationen in den ProBaug-Daten.

Ich hänge einmal meinen Vergleich dazu als Tabelle an.

Jedenfalls, da durch das PlugIn die Tabellen

probaug.verfahrensart

probaug.vorhaben

„fest“ in die DB geschrieben werden, wollen wir weniger gerne die Tabellen abändern um dann bei der nächsten Aktualisierung des PlugIn ggf. zu vergessen die Tabellen zu erneuern.

Mein Vorschlag ist, statt des Schreibens dieser Lookuptabellen soll das PlugIn bei seiner Aktualiserung Materialized Views für Verfahrensart und Vorhaben basierend auf der Tabelle probaug.bau_akten als Lookuptabelle anlegen. Dann würden wir jeweils beim Einlesen der Probaugdaten nur den Materialized View refreshen und hätten immer die aktuellen Kategorien.
Wir könnten sicher auch jetzt bereits die Tabellen löschen und periodisch durch eigene aktuelle ersetzten, aber das erscheint mir als unschönes rumgebastel und ändert ja nichts an dem „Bug“ im PlugIn.

Die Spalte ID in den beiden Tabellen legt wohl die Position  im Auswahlfeld fest. Hier könnte man nun entscheiden, ob man hier nach auftretenden Fällen sortiert oder alphabetisch. Da es mittlerweile doch sehr viele Ausprägungen gibt tendiere ich zu alphabetisch.

Wenn es dir als sinnvoll erscheint, dass auf die Wunschliste zu setzten oder in den BugReport, dann würde ich dich hiermit darum bitten oder auch einen alternativen Vorschlag umzusetzen. Man könnte z.B. auch die Lookup-Tabellen per Trigger an der Tabelle bau_akten aktualisieren, oder? Dann wären alle notwendigen Schritte im Quellcode des PlugIn.

Falko


Als Views umsetzen und im LK EE evtl. als materialized Views.

Aktuell ist es möglich über die Anzeige der Versionen die Veränderungen am Flurstück nachzuvollziehen. Allerdings sind dort keine Veränderungen hinsichtlich des Grundbuchs enthalten. Für das Jagdkataster (und sicherlich nicht nur dort) ist es unter Umständen wichtig, die Eigentumsverhältnisse chronologisch nachzuvollziehen. Das geht momentan (meines Wissens nach) nur recht umständlich. Sinnvoll wäre eine Funktion, welche für das Flurstück eine Eigentümerhistorie anzeigt. Dabei sollen alle betroffenen Grundbücher (bei Umschreibung auf ein anderes Grundbuch) mit ihren Eigentümern und der Wechsel von Eigentümern aufgelistet werden. 

Eigentümerwechsel in die Versionen aufnehmen.

Das Attribut Rissnummer in der Nachweisverwaltung kann durch Verwendung als Primary- oder Secondary-Attribut zum Pflichtfeld werden. Trotzdem kann es sein, dass die Vergabe der Rissnummer bei FFR, KVZ und GN zwar sinnvoll, bei Karten, Plänen etc. aber wenig sinnvoll oder sogar kontraproduktiv ist. Wie könnte kvwmap darauf reagieren?

Neue Spalte in u_dokumentarten ob primäres Ordnungskriterium Pflicht ist.
Die Dokumente, die kein primäres Ordnungskriterium haben, werden pro Flurordner alle in einem Unterordner "keine_nummer" abgelegt. Dadrin gehts dann weiter mit dem Dokumentartordner und darin dann die Datei. Beim Dateinamen wird statt des primären Ordnungskriteriums die Nachweis-ID verwendet.

Umstellung des bisherigen Hashings auf ein aktuelles Hash-Verfahren.

Bei der Sachdatenanzeige im schwebenden Fenster sollte genau wie beim GLE die Geometrie gehighlightet werden, auf der der Cursor gerade steht.

Viele Nutzer hantieren zwar mit Shapes, haben jedoch relativ wenig Ahnung - also z.B., dass es die bekannten 3 Dateien beim Import sein müssen. Vorschlag für den Text: "Unterstützte Formate: Shape (*.dbf, *.shp, *.shx), …"

Die Verwendung von Layer-Parametern sollte auch auf Connection und Processing in der Layerdefinition ausgeweitet werden.
Zum Beispiel könnten Raster-Layer (auch WMS!), wie das DGM, beispielsweise über das Attribut Processing mit "SCALE=$min,$max;SCALEBUCKETS=..." vom Nutzer eine Histogramm-Streckung erhalten.

Es gab den Wunsch, dass das zuletzt ausgewählte Format und bei Geometrieformaten das zuletzt ausgewählte Koordinatenreferenzsystem beim Datenexport rollenbezogen gespeichert wird.

Layer-Rollen-bezogen Format und Koordinatensystem speichern.

Wenn eine Stelle neu angelegt wird, müssen eigene Flurstückslisten, die man mit dem Sachdatenlayoutdruck-Editor erstellt und in der Flurstückssachdatenanzeige zur Verfügung stellt, layerseitig der neuen Stelle zugeordnet werden. Das kann mühsam sein.

Könnte ein Mechanismus wie die "ALB-Funktionen" für diese Layouts erzeugt werden, der die Layer automatisch der Stelle zuordnet, wenn das/die entsprechenden Layouts zugeordnet werden?

Evtl. hier das Konzept der Stellenhierarchie weiterentwickeln und dafür verwenden.

Man kann in den Layer-Optionen eine Beschriftung zulassen. Die Optionen sind die in data genannten Datenbank-Feldnamen. Zum einen erkennt der Nutzer diese i.d.R. nicht. Zum anderen möchte man viele der Attribute gar nicht für die Beschriftung anbieten (oid).
Man müsste definieren können, welche der Data-Attribute für die Beschriftung zur Verfügung stehen sollen und welchen Aliasse sie bekommen sollen.

Aliasnamen aus den Query-Attributen nehmen und oid generell weglassen.

Wie sollen grundstücksgleiche Rechte ausgegeben werden? Erbbaurecht zeigen wir beim Flurstück an. Gebäudeeigentum jedoch nicht...

umsetzen

Im Sachdatendruck ist jetzt ein Maßstabsbalken in der Karte enthalten - mit der Folge, dass Teile der Geometrie des Objekts überdeckt werden. Entweder der Maßstabsbalken wird deutlich kleiner (da geht noch was) oder er wird unterhalb des Kartenrahmens platziert.

erstmal kleiner machen

Beim Aufruf von index.php?go=ALK-Flurstueck_Auswaehlen&go_next=Nachweisformular landet man in der Nachweiserfassung, wobei Gemarkung und Flur schon vorausgewählt sind. Die Information dazu stammt jedoch aus der Bildmitte - und das liegt nicht immer in der recherchierten Geometrie und im schlimmsten Fall sogar in einer anderen Gemarkung und Flur.
Schön wäre, wenn die Kombination go=ALK-Flurstueck_Auswaehlen&go_next=Nachweisformular die Information zu Gemarkung und Flur aus der recherchierten  Geometrie (pointonsurface) und nicht aus dem Kartenmittelpunkt holen würde.

So umsetzen

Es wurde der Wunsch geäußert, dass man die Suche nach (einer größeren Gruppe von) Flurstücken speichern kann, um diese Suche zu späteren Zeitpunkten immer wieder ausführen zu können. Flurstücke, die dann historisch geworden sind, müssten als solche erkennbar sein.

eigene Suche speichern und ausgefüllte Suchmaske wieder anbieten

Seit MS-Version 5.6 gibt es den LABEL-Parameter REPEATDISTANCE zur wiederholten Darstellung von Beschriftungen entlang von (Multi-)Linien. Es wäre toll, wenn kvwmap diesen Parameter ebenfalls anbieten würde.

Mit der Verwendung von Untergruppen besteht der Wunsch, diese Dokumenenart auch im Dateinamen zu erkennen.

zusätzliches Feld Abkürzung für die Unterdokumentarten. Wenn es befüllt ist, wird es verwendet, wenn nicht, wird das der Hauptart verwendet.

Raus mit allen Schriften, die nicht funktionieren oder die grauselig sind! MonoBold? ZapfDingbats???

Beim Style-und-Label-Editor wäre es gut, wenn dort die Maßstabsanzeige und -auswahl bei der Karte wäre.

Bei der Flurstücksrecherche kann eine Datei mit Flurstückskennzeichen in ALKIS-Schreibweise importiert werden. Vorschlag:
1. Nicht nur bei "go=Flurstueck_Auswaehlen", sondern auch bei "go=ALK-Flurstueck_Auswaehlen" sollte eine Meldung kommen, welche Flurstücke aus der Importdatei es nicht gibt und welche historisch sind.
2. Es sollte grundsätzlich eine Meldung kommen, wenn die Syntax einer Zeile aus der Import-Datei nicht korrekt ist.
3. Es sollte zusätzlich auch möglich sein, Flurstückskennzeichen in einer vereinfachten Schreibweise anzugeben. Beispiel: Statt "132488011001010002__" alternativ auch "13-2488-11-101-2".

Beim Import einen Hinweistext anzeigen, welche Formate zulässig sind.

Meldung der nicht gefundenen Flurstücke bei go=ALK-Flurstueck_Auswaehlen

Die Nachweissuche ermöglicht auch die Suche nach einer Antragsnummer. Dieses Feld verlangt aber den genauen Eintrag des für den Nachweis gespeicherten Wert der Antragsnummer. Schön wäre es, wenn ähnlich wie bei der Namenssuche alle ähnlichen Werte mit ausgegeben werden. Zur exakten Suche könnte man dann auch eine Checkbox hinterlegen.

Es wäre schön, wenn die Nutzer in der Gruppe "Suchergebnis" den Themen nachträglich eine andere Farbe / Transparenz / Schraffur geben könnten.

für Rollenlayer in den Layeroptionen Farbwähler und Häkchenfeld für Schraffur hinzufügen

Es wäre schön, wenn die Zeilen bei go=Stellen_Anzeigen beim Hovern unterlegt wären und wenn beim Löschen einer Stelle die Frage geändert würde in "Sind Sie sicher, dass Sie die Stelle XY löschen wollen?"

Wenn im Sachdatenlayout-Editor der Typ "Datensätze fortlaufend" gewählt wurde, könnte kvwmap eine farbige Hinterlegung der Tabellenüberschriften, der (alternierenden) Datenzeilen und möglicherweise der Zeilen- und Spaltenrahmen anbieten. Entweder, indem der Nutzer die Farben selbst wählt oder indem fertige Farbkombinationen angeboten werden, ähnlich wie Excel das auch macht.

für die Datenzeilen in einem Feld eine Farbe definieren

evtl. farbige Rechtecke einführen

Für die Freitexte im Sachdatenlayout-Editor bietet sich ein kleiner wysiwyg-Editor wie z.B. "summernote" an. Damit kann der Nutzer einzelne Teile des Textes als fett oder unterstrichen formatieren, ohne mit der HTML-Notation hantieren zu müssen.

Wenn das umgesetzt wird, brauchen bei Freitexten die Bold-Schriftarten nicht mehr angeboten werden.

Theoretisch wäre PDFClass auch in der Lage, Rahmen um einzelne Teile des Textes zu ziehen. Praktisch hat das aber vermutlich eher keine Bedeutung (?). Deswegen bietet es sich an, bei den Freitexten zusätzlich ein Häkchenfeld "Rahmen" für den ganzen Freitext zu schaffen.

ausprobieren

bei den Layergruppen wäre es schön ein Feld zuhaben, welches anzeigt wie viele Layer dieser Gruppe zugeordnet sind

Wenn ein Attribut nur sichtbar in Abhängigkeit eines anderen Attributes ist ("sichtbar wenn") funktioniert das bisher nur in der normalen Sachdatenanzeige.
Konsequenterweise sollte das auch in der Tabellenansicht umgesetzt sein.

Bsp: Anzeige einer Kontaktinformation nur wenn Eigentümer zugestimmt hat.

Array-Einträge könnten beim CSV-Export in einem Feld durch Umbrüche getrennt erscheinen, d.h. vor allem ohne geschweifte Klammern.

Es wäre praktisch, wenn beim Speichern der Themenauswahl auch der Status (aufgeklappt/eingeklappt) der Themengruppen mitgespeichert wird oder die Gruppen der aktiven Layer geöffnet werden.

(Als Admin springe ich zwischen verschiedenen "Ansichten" mit unterschiedlichen Themen und dann würden auch immer gleich die richtigen Gruppen aufklappen.)

Dokumente im Druck rasterförmig, ansonsten untereinander

Es wird vorgeschlagen die Lage zum Flurstück zukünftig mit Ortsteil auszugeben:

statt:
Lage  	Pätow-Steegen
Am alten Sportplatz 1

neu:
Lage  	Pätow-Steegen OT Steegen
Am alten Sportplatz 1

Die Daten der Ortsteilzuordnung könnten von "Gemeindeteile M-V" aus OpenData HRO
https://www.opendata-hro.de/dataset/gemeindeteile_mecklenburg-vorpommern
geholt werden.

2 config-Parameter: LAYER_ID_ORTSTEILE und ATTRIBUT_ORTSTEILE, die auf eine Tabelle verweisen, die mit den Flurstücken verschnitten wird

Für eine bessere Darstellung von  Dokumenten / Bildern, die in Arrays gespeichert werden, wird eine rasterbasierte Anzeige gewünscht. 

Parsen der eingegebenen Filter auf syntaktische Richtigkeit. Bei einer syntaktischen falschen Eingabe ist der Layer fehlerhaft. Kann nur durch ab- und anmelden wieder geheilt werden.


Bei reset_layers auch den Filter löschen

Anpassen der Empfindlichkeit der Auswahlfelder. Eventuell wie bei den sonstigen Auswahlfeldern diese mit einem Klick aktivieren.

Über Klick öffnen

Bislang ist es nur möglich, den Sachdatendruck in A4 Hochformat zu erstellen. Um ein paar mehr Informationen in eine Zeile darstellen zu können, wird auch das Querformat benötigt.

Ergänzen der Operatoren um >= und <=

Schön wäre es wenn es die Möglichkeit gäbe, den Standardtext der E-Mail anzupassen, die generiert wird, wenn man als Admin das Passwort eines Nutzers zurücksetzt.

config

Dateien im UKO-Format sollten nach Möglichkeit ebenfalls über go=Daten_Import angezeigt werden.

Der Download einer Unterlagenzusammenstellung sollte vollständig mit den zugehörigen Suchparametern gespeichert werden. Außerdem sollten berechtigte Stellen die Möglichkeit bekommen, auf diese Protokollierung zuzugreifen.

Auflistung der Übergabeprotokolle

Die Anzeige des neu-Buttons für einen untergeordneten Datensatz (Subform) sollte nur erscheinen, wenn der Datensatz keiner Editiersperre unterliegt.
Der Datensatz ist dank Editiersperre nicht bearbeitbar, aber innerhalb des Formulars darf dann ein verlinkter Datensatz angelegt werden. Ist irgendwie nicht konsequent.

Man möchte den neu-Button ja nur verhindern, wenn die Editiersperre greift. In den Fällen ohne einer Editiersperre sollte über den neu-Button ja das Anlegen von Datensätzen möglich bleiben.

- Statt "Gültigkeit" kürzer "gültig"
- Statt "0" / "1" bei "gültig" und "geprüft" besser "ja" / "nein"

ja und nein

Die „>>“ und „<<“ als Values von Buttons gegen was Eleganteres tauschen

Über CSS und class realisieren.

Der "Bestand" in der Flurstücksanzeige ist ein Relikt aus ALB-Zeiten. Ich schlage eine Anpassung an Aussehen und Begrifflichkeit des ALKIS-Flurstücksauszugs vor:
- Begriff "Bestand" komplett durch "Buchung" ersetzen
- "Eigentümer" als Oberbegriff ganz weg, stattdessen "Buchung", "Buchungstext" und "Eigentümer" getrennt
- Begriff "BVNR" komplett durch "Laufende Nummer" ersetzen (auch in der Grundbuchblattsuche/-anzeige!)
- Die Buchungsart gehört zum Grundbuchblatt, also vorneweg
- Die laufende Nummer muss die letzte Info sein
- Der komische Schlüssel kann weg

Beispiel:
"
Buchung:
  Wohnungs-/Teileigentum 132902-12963, Laufende Nummer 1

  9,295/1000 Miteigentumsanteil am Grundstück verbunden mit dem
  Sondereigentum an der Wohnung im EG und 1. OG (Haus G-J),
  Nr. 1 laut Aufteilungsplan

Buchungstext: Sondernutzungsrechte sind vereinbart

Eigentümer:
  1.1 Max Mustermann
  ...
"

Wenn eine Stelle keine lesenden Rechte am Eigentum hat, erscheint nur die 1. Zeile der Buchung!

Beispiel:
"
Buchung:
  Wohnungs-/Teileigentum 132902-12963, Laufende Nummer 1
"

Kritik gibt es immer wieder an den Vorschaubildern im GLE:
- Geht man mit dem Cursor auf ein Bild, vergrößert es. Das wird oft als lästig empfunden.

-> verzögert vergrößern

- Vergrößert es, werden hochformatige Bilder deutlich größer als eigentlich gleich große querformatige. Vorgeschlagen wurde hier z.B., dass die Vergrößerung nicht nach Breite, sondern nach Fläche funktioniert.

Breite und Rahmen auch für Freitexte.

1. Sortierungen gehen nicht.
2. Default für Obergruppe beim Anlegen einer neue Gruppe nicht 0 sondern NULL
3. Anzeige welche Layer in jeder Gruppe sind.

Der Nutzer sollte in den Optionen einstellen können, ob er, wenn bei der Sachdatenabfrage über die Karte nichts gefunden wurde, eine Info bekommen will oder nicht. Aktuell wird ja immer eine Meldung ausgegeben, das zu einem Thema nichts gefunden wurde. Wenn diese Anzeige unterdrückt wird, ist es für den Nutzer übersichtlicher. Bei der Layersuche soll alles beim Alten bleiben.

Sortierung ändern, die Layer, zu denen nichts gefunden wurde zum Schluss anzeigen

Die Reihenfolge der Attribute in der Erfassungsmaske/Sachdatenanzeige lässt sich zwar über das Query steuern. Es ist jedoch deutlich komfortabler die Inhalte der Spalte order in der Tabelle layer_attributes über den Attributeditor zu beeinflussen. Idealerweise per Runter/Raufschiebpfeil hinter jedem Attribut. ( oder per drag n drop :)  ) 

Und Gruppennamen beim Speichern automatisch auffüllen.

Wir haben immer öfter das Problem, dass Administratoren Änderungen an Daten, seien es Geodaten in der Postgres- oder Konfigurationsdaten in mysql-Datenbank in einer Entwicklungs- oder Testanwendung vornehmen und diese in ein Produktionssystem übernehmen möchten.

Prinzipiell können wir ja Datenmigrationen in kvwmap handhaben. Das ist aber nur für Daten gedacht, die kvwmap allgemein benötigt oder in einem Plugin, die in diesem speziellen Plugin allgemein benötigt werden.

Wir können noch keine Daten behandeln, die für eine spezielle Anwendung oder ein spezielles Portal überführt werden sollen. Dafür bräuchte man eine Lösung, bei der das Programm bei Programm-Updates die Datenmigrationen zwar berücksichtigt, aber die Migrationen auf nur auf den Servern auftauchen für die sie bestimmt sind.

Vorschlag:
Man kann in der Konfiguration eintragen in welchem Verzeichnis anwendungsspezifische Datenmigrationen liegen. Das würde ich gleich custom nennen und da würde ich bei der Gelegenheit gleich mal alle custom-Dateien aus kvwmap mit reinpacken. Dieses Custom-Verzeichnis liegt außerhalb vom kvwmap Ordner und damit auch außerhalb dessen Repository. Das Verzeichnis kann dann selber ein git-Verzeichnis sein (muss aber nicht).
Der Update-Prozess in kvwmap schaut dann nach ob in diesem Verzeichnis Datenmigrationen enthalten sind und führt diese zusammen mit den Migrationsdateien aus dem Core in der richtigen Reihenfolge aus. Die Reihenfolge der Datumsangabe in der Migrationsdatei stellt sicher, dass die Änderungen in der mysql- und postgres-DB zu dem jeweils aktuellen Schema passen in den Ständen in denen die Änderungen auch wirklich vorgenommen wurden.
Wenn wir gleich alle custom-Sachen in den externen custom Ordner auslagern haben wir den Vorteil, dass wir die Inhalte auch über ein git-Repository syncen und verfolgen können. Das ist wichtig, denn bei einigen sind die Custom Ordner schon sehr vollgestopft mit eine ganzen Menge an logic und wichtigen Sachen und dies Dinge werden mit unter auch von mehreren Personen fortgeführt.

Was noch zu klären ist wie wir die Zeiten der Datenmigration mit den anderen Migrationen syncronisiert bekommen. Entscheidend beim Ausführen der Migration auf dem Zielsystem ist dann nicht wann die Migrationen erstellt wurden, sondern wann sie ausgeführt werden.
Man muss eigentlich immer nur dafür sorgen, dass sein eigenes Develop-System vor einem Update alle Logs in Datenmigrationen beendet. Und danach neue anfängt. In der anderen Anwendung, die als Produktionssystem läuft müssen dann alle Datenmigrationen ausgeführt werden bevor das Update läuft. Das heißt der Update-Prozess von kvwmap muss eigentlich nur vor jedem Update schauen ob es noch unausgeführte Datenmigrationen gibt, diese vorher ausführen und dann den Update machen.

Die Datenmigration muss man auch machen können ohne Update. Das Zielsystem muss sich also eigentlich nur merken welche Datenmigrationen es schon ausgeführt hat. Das Entwicklungssystem schreibt sich selbst natürlich auch ein welche Datenmigrationen es angelegt hat, weil sie im Falle einer Datenmigration, die von wo anders kommt die nicht noch mal selbst an sich selbst ausführen soll.
Also wer Änderungen aufzeichnet, schreibt in das custom Verzeichnis als Datum wird das aktuelle genommen. Das custom Verzeichnis kann von zwei Anwendung gleichzeitig genutzt werden, muss aber nicht. Wird es von zwei gleichzeitig genutzt, sieht Anwendung Production (P) im custom beim Update die Migrationsdateien von Anwendung develop (D), welche diese aufgezeichnet hat und umgekehrt. So könnte man sogar Änderungen an der Konfiguration in Produktion machen und in Develop übernehmen. Was natürlich nicht preferiert wird. System P und D müssen auf den gleichen branches laufen.

Wenn eine Migration in kvwmap-core oder plugin ausgeführt wird, muss vorher das offene Log der Datenmigration beendet werden und es muss eine neue Datenmigrationsdatei angelegt werden, die 1 Sekunde älter ist als die letzte eingelesene Migrationsdatei von kvwmap. Wenn dann eine andere Anwendung migriert, werden die Datenmigrationsdateien aus dem custom-Ordner in der richtigen Reihenfolge ausgeführt. Immer nach einem Update eine neue Datenmigrationsdatei, die zu dem letzten Schema passt.

ToDo: Was ist also zu tun?
- Man muss einen Mechanismus schreiben, der Änderungen in eine neue Migrationsdatei loggen kann, damit man Änderungen (z.B. an der kvwmapdb nicht händisch erstellen muss)
- Die Änderungen müssen vom Admin separat und in eigener Verantwortung commited und gepusht werden.
- Der Updateprozess muss auch dieses Repository pullen falls es ein Git-Verzeichnis ist.
- Der Updateprozess muss die Migrationsdateien mit ausführen (in der richtigen Reihenfolge zusammen mit den anderen Schema-Migrationen).
- Die Sachen, die vorher in custom Ordner standen, verteilt auf die ganzen Unterordner von kvwmap werden nun aus dem einen externen custom-Ordner geholt.
- Anpassung von Sicherungsscripten, die den kvwmap-Ordner separat gesichert haben. Nun auch zusätzlich die Custom Ordner sichern.

Das ganze gilt nur für den Übergang zwischen einer Anwendung zu Entwicklungszwecken und der Produktionsumgebung. Für Test- und Demozwecke würde ich noch ein drittes System vorschlagen. Das wird dann aber durch Kopieren der ganzen Anwendung und Datenbank und Datenverzeichnis (optional als Link) erstellt. Ein Script zum Kopieren gibt es schon in tools/update_test.sh 

Eigentlich müsste es kvwmap, kvwmap_dev, kvwmap_test und kvwmap_demo geben. Wobei kvwmap_test und kvwmap_demo durchaus gleich sein können mit dem Unterschied, dass kvwmap_test immer wieder überschrieben werden kann, weil ja bei tests auch Müll produziert werden kann, der mal weg muss. kvwmap_demo hingegen sollte einen gut definierten Datenbestand haben, mit dem man alles mögliche testen kann. kvwmap_demo sollte also nur von Entwicklern oder Admins geändert werden können und zwar im Zusammenhang mit neuen Möglichkeiten, die es zu testen oder demonstrieren gibt. Das Testsystem wird dann immer neu aus dem demo-System heraus überschrieben. kvwmap_demo wird also nur angefasst wenn neue Testdaten dazukommen sollen. Möchte man kvwmap_dev testen, muss man zunächst kvwmap_demo auf die gleiche Software-Version bringen und kann dann von kvwmap_demo aus per update_test.sh eine kvwmap_test erzeugen.

Man könnte jetzt noch darüber nachdenken ob man auf kvwmap_demo verzichtet und statt dessen bestimmte Teile von kvwmap_dev als kvwmap_test kopiert, z.B. nur ein bestimmtes Schema. Aber das ist sicher nicht einfach, weil man dann auch nur bestimmte Teile (Layer etc.) aus kvwmapdb_dev extrahieren müsste. Besser wäre wohl schon eine separate Version kvwmap_demo, die ausschließlich dafür da ist Testdaten zu erzeugen oder zu verwalten. Also:

kvwmap: Produktion Änderungen per Pull, Core- und Custom-Migrationen ausführen
kvwmap_dev: Entwicklung Änderungen per Pull, Core-Migrationen ausführen (Änderungen von GDI-Service per push senden) Custom-Migrationen schreiben.
kvwmap_demo: Zur Erstellung und Verwaltung von Demo-Daten (muss immer so aktuell sein wie kvwmap_test sein soll. In kvwmap_demo wird nicht getestet! Nur Demodaten erzeugt und verwaltet!) Eventuell kann kvwmap_dev als kvwmap_demo verwendet werden.
kvwmap_test: Zum Testen und kaputt machen (wird immer per Copy aus kvwmap_demo oder kvwmap_dev heraus erstellt)

Stefan und ich besprechen das noch mal bevor ich das auf einen der nächsten Anwendertreffen mal vorstelle an einem Beispiel.

Unmittelbare Nutzer sind das LUNG mit Wasserrecht und MVBio sowie der Bauleitplanserver MV und SWAMS wo überall Testanwendungen laufen.

So eine Umgebung mit kvwmap, kvwmap_dev, kvwmap_demo und kvwmap_test würde ich dann auch in die Containerlandschaft vom kvwmap-server schon fest einbauen, so dass bei Neuinstallationen automatisch diese Ordner, Datenbanken und Anwendungen schon angelegt sind.

kvwmap sollte es dem Nutzer bei WMS-Layern (bei go=WMS_Import) ermöglichen, zusätzlich zum WMS auch eine SLD zu laden.

kvwmap sollte es auch ermöglichen, dass aus den Klassen eines Layers eine SLD exportiert werden kann.

Markus Hentschel testet.


27.02.: Markus Hentschel hat getestet. Prinzipiell funktioniert die Angabe eines eigenen SLD natürlich, Beispiel:
https://www.umweltkarten.mv-regierung.de/script/mv_a3_hwrmrl_wms.php?SERVICE=WMS&request=getMap&VERSION=1.3.0&LAYERS=t3_hwrm_gh_asl200_l&CRS=EPSG:25833&width=600&height=500&BBOX=355771,6022428,375473,6038601&FORMAT=image/png&SLD=http://geodienste.lk-vr.de/sld/POLYGON_SYMBOLIZER.XML

kvwmap kann die Angabe "&SLD=..." in der connection interpretieren. Also ist die erste Forderung, das eigene WMS-Styling im GLE mit SLD, bereits erfüllt. Bei mir gings allerdings nur, wenn ich die SLD-Datei nicht per https, sondern nur per http aufgerufen habe.

Bei go=WMS_Import müsste der Nutzer eine SLD-Datei hochladen, die dann temporär auf dem Server in einem öffentlichen Verzeichnis gehalten und bei der WMS-Anzeige verwendet wird. Wenn der WMS aus den eigenen Importen gelöscht wird, muss auch die SLD-Datei gelöscht werden.

Alternativ (eigentlich die nutzerfreundlichere Variante) könnte kvwmap bei go=WMS_Import dem Nutzer je nach Geometrietyp bestimmte Styling-Möglichkeiten anbieten - bei Fläche z.B. Füllfarbe- und Transparenz sowie Umringsfarbe, -stärke und -transparenz. Diese Angaben werden in eine temporäre SLD gespeichert und weiter wie oben.

- diese Variante umsetzen, d.h. aus Styling SLD machen und im WMS verwenden

In der Legende müsste beim Themennamen klargemacht werden, dass das Styling nicht mehr vom Dienst-Anbieter stammt, sondern ein eigenes ist.

Die Anzeige der Kartenausschnitte sollte nach Datum, Benutzer und Kommentar sortierbar sein.

WFS-Dienste sollen ebenfalls im Attribut-Editor, in der Layerattribut-Rechteverwaltung und in der Filterverwaltung auftauchen. Das Highlighting soll funktionieren. Die Recherche soll funktionieren, ebenfalls "zurück zur Suche". In der Hoppla-Seite muss die Layer-ID auftauchen. Beim Einbinden des Dienstes soll es unnötig sein, auch den workspace des Dienstes mit anzugeben. Es sollte - ähnlich wie bei WMS - imHintergrund geprüft werden, ob der Dienst funktioniert.

Wenn ein neuer Layer aus einem bestehenden heraus angelegt wird, vergisst man manchmal, die Layer-ID zu löschen. kvwmap sollte dann 1. eine Abfrage liefern, ob man wirklich einen neuen Layer anlegen will und 2. die angezeigte alte Layer-ID ignorieren und den neuen Layer unter neuer ID speichern.

Das da oben alles nicht aber:

Layer-ID-Feld beim Neuanlegen anbieten.

Wenn ich einen Gemarkungsschlüssel eingebe, wird in der Auswahlliste der zugehörige Gemarkungsname vorausgewählt. Wenn ich das Feld Gemarkungsschlüssel leere, müsste kvwmap in der Auswahlliste "--Auswahl--" anzeigen und nicht die alphabetisch erste Gemarkung.

Die Wahl der Stellen sollte nicht über die Optionen erfolgen. Es gibt bereits einige Implementierungen von kvwmap in denen die Stellenwahl ohnehin schon im Header verbaut ist und in der Optionendarstellung ausgeblendet. Das wechseln der Stelle sollte auch einfacher möglich sein als mit den 3 Klicks, die es jetzt sind. Man könnte die Stellenwahl in den header fest mit einbauen. Die Optionen lassen sich dann über einen Einstellungen Icon erreichten und gelten immer in der aktuellen Stelle.
Das Optionen-DIV sollte vertikal scrollbar sein.
Pro:
- Stellenwechsel und Optionen sind zwei unterschiedliche Dinge, die in einer Seite sind.
- Man kann Stellenwechsel auch woanders einbauen und muss dann das dann nicht in Stelle_Wählen ausblenden
Con:
- Nutzer haben sich vielleicht schon daran gewöhnt
- Man kann die Optionen erst ändern, wenn man in der Stelle ist

in den Standard-header übernehmen
und Logout-Symbol direkt in den Header

Wenn in den Sachdaten eines Objekts in einem Attribut geändert wird, das für die Klassendefinitionen benutzt wird - könnte dann die Karte nicht automatisch neu laden, wenn man "Sachdatenanzeige in schwebendem Fenter" angehakt hat?

An diversen Stellen sind Filtermöglichkeiten eingebaut, z.B. Druck oder Fachdatensuche. Der Vorschlag zielt auf eine Modernisierung des Looks. Außerdem soll der Nutzer zukünftig beim Filter speichern können, ob der Filter beim Aufruf der Seite schon gesetzt wird:
https://kvwmap.de/index.php/Datei:filter_kvwmap_vorschlag.png

bestehende Filter als Auswahlfeld
Filtersymbol aus Vorschlag als + Symbol darstellen
Links durch Buttons ersetzen
"Filter bei Aufruf setzen" weg

In der Adresssuche und auch in der Flurstückssuche muss der Nutzer immer eine Kette von attributabhängigen Auswahllisten durchlaufen. Genauso im GLE, wenn in einem Thema die Adressen des Liegenschaftskatasters verwendet werden sollen. Das ist wenig nutzerfreundlich und könnte durch den Geo-Namen-Such-Dienst abgelöst bzw. erweitert werden.

Formularelementtyp: Geonamensuche, im Optionen-Feld werden die Attribute des Resultsets definiert, die übernommen werden sollen

Im Sachdatendruckeditor kann man eine Karte erzeugen. Der fehlt ein Maßstabsbalken.

Nach go=ALK-Flurstueck_Auswaehlen&go_next=Nachweisrechercheformular (Suche Flurstück in der Karte und gehe anschließend in die Nachweisrecherche) könnte die Geometrie des/der gesuchten Flurstücke bereits als Suchpolygon ausgewählt sein.

Anzeigen einer vordefinierten Farbpalette und speichern des RGB-codes

- Alternativ zur Auswahl im Header: Auswahl in den jeweiligen Themenoptionen
- Beim Speichern der Auswahl Layernamen aktualisieren, wenn Layername dynamisch
- Beim Speichern der Auswahl Kartenbild neu laden, wenn Layer sichtbar
- Vielleicht statt "Speichern" ein passenderer Begriff: Übernehmen

In der Suche findet man keine Straßen zu denen (noch) keine Hausnummern existieren. Kann man die Suche dahingehend erweitern?

Beispiel von Herrn Schmidt

Darstellung der Query in formatierter schreibweise. Parsen des SQL mit SQL-Parser, z.B. php_sql_parser
Ermöglichen, dass Argumente in der Order Klausel auch Aliase von Tabellen verwenden können (Order wird jetzt außen angehängt und dort sind die Aliase nicht bekannt.)

Zeilenumbrüche beibehalten

und sortieren

Links "Ändern" / "Löschen" ersetzen durch Symbole wie bei den Layergruppen.
Gilt auch für die Seite Benutzerdaten.

Der Layereditor ist sehr unübersichtlich und man muss viel herumscrollen und klicken um zB. zwischen Layereditor und Style- und Labeleditor hin und her zu wechseln. Auch sind Optionen, welche eigentlich zu den Klassen (Styles) oder zu den Labels gehören im Layereditor und nicht im Style- und Labeleditor. 
Dazwischen gestreut sind Knöpfe für Attributeditor und Rechteverwaltung und dann Links für den Styleeditor.
Eine integrierte Layereigenschaften-Seite mit so etwas wie Tabs an der Seite oder oben für ALLGEMEIN | ATRRIBUTE | KLASSEN | RECHTE | STELLENZUSWEISUNG | OWS-PARAMETER könnte diese verschiedenen Editoren auf eine Seite bringen und die Optionen entflechten, ordnen und leichter zugreifbar machen.

Diese Eigenschaftenseite der Layer könnte dann für alle sichtbaren Layer über das Kontextmenü in der Legende erreichbar sein. Man käme direkt und schnell zu den Einstellungen des Layer, den man ohnehin gerade in Betrachtung hat.

Klassen erstellen/löschen über  + | - (Mülleimer) | AUTO 
-> Symbole statt Links verwenden, wie bereits bei Layergruppen, -parameter, Menüdaten 


ja, umsetzen und zusätzlich Klassen-IDs anpassbar machen

Für Mapserver-Attribute mit fester Codeliste wünschte ich mir ein Auswahlfeld, statt einer freien Eingabe. Z.B. kann das Label-Attribut POSITION bei Mapserver die Werte [ul|uc|ur|cl|cc|cr|ll|lc|lr|auto] annehmen. In kvwmap soll man jedoch entsprechend [0|6|2|5|8|4|3|7|1|9] eingeben. Die entsprechende Position kann sich niemand merken -> Auswahlfeld mit den original MapServer-Parametern. Weiteres Bsp. ANTIALIAS. Wenn hier eine Checkbox wäre, erschließen sich jedem die möglichen Eingaben sofort. ...

so umsetzen

Es wurde der Wunsch geäußert, dass man in der Voransicht eine art Lupe einsetzen kann, die das Dokument an der Stelle stark vergrößert zeigt. Die Voransicht selbst müsste dann vielleicht nicht mal so groß sein.

entweder neue größere Vorschaubilder generieren, verkleinert anzeigen und mit Lupenfunktion versehen

oder größere Vorschaubilder on the fly mit der Lupe generieren

- Wenn in den Optionen die Größe auf automatisch eingestellt ist, sollte das Rechercheergebnis auch über den gesamten Bildschirm dargestellt werden.

im Edge testen

- Bei der Überarbeitung eines Nachweises kann die Erfolgsmeldung nach 1-2 Sekunden automatisch ausgeblendet werden, ohne dass man auf OK drücken muss. Beim GLE ist es schon so.

ok

- In der Anzeige der Nachweise im GLE (Aufruf über "bearbeiten") wird sich ein Link zurück auf das Rechereergebnis gewünscht.

über eigene Template, welches den GLE einbindet einen Link hinzufügen

- Beim Dokument überarbeiten wäre es gut, wenn beim Ändern der "Geometrie übernehmen von" das Polygon des Nachweises erhalten bleibt. So wie es beim Erfassen und Suchen schon geht.

Bug?

Für das Zuweisen (Verschmelzen) von Umringen mehrerer Risse zu einem KVZ wird die Möglickeit benötigt, für die Geometrieübernahme mehrere Dokumente auszuwählen. Abändern der Radiobuttons zu Checkboxen.

"Alle der Messung" dauert relativ lange. Der Nutzer sollte deshalb den Haken jedes mal explizit setzen müssen. Bei erneutem Aufruf der Recherche uber den Menüpunkt sollte sich kvwmap den Haken also nicht gemerkt haben. Wenn man aus der Trefferliste kommt dagegen schon.

Manchmal (bei wenigen Optionen) erscheint eine Auflistung mit Radiobuttons nutzerfreundlicher als eine Auswahlliste, sowohl in der Sachdatensuche als auch -anzeige.

Radiobuttons auch in der Suche

Wenn man nur die Angaben zu Vermessungsstelle und Messungsdatum hat (eigentlich ein Klassiker), dann kann man im Moment mit diesen Angaben nicht alle Nachweise über eine Abfrage bekommen. Es fehlt sowas wie "alle der Messung" direkt in der Suchmaske.

"alle der Messung" auch in der attributiven Suche

Denkbar ist im Koordinatenzoom bzw. in der Koordinatenabfrage auch ein Zoom auf bzw. eine Abfrage von Plus Code (siehe https://plus.codes/). Dafür kann der OLCA-Dienst der Hansestadt Rostock eingebunden werden: https://geo.sv.rostock.de/olca.html

Werden mehrere Nachweise gelöscht, müsste die Sicherheitsabfrage auf den Plural angepasst werden. Vielleicht sollte auch eine Auflistung der zu löschenden Dokumente erfolgen.

Sachdatendruck Zum Vorschlag: Möglichkeit einen "Kopf" zu definieren, möchte ich noch erweitern. Man kann das Dokument ja wie folgt unterteilen, Kopf; Hauptteil; Fußzeile "jede Seite" sowie Fußzeile "letzte Seite". Der Anfang und das Ende des Hauptteils kann über eine y Koordinate (y Anfang/ y Ende)gesteuert werden.
Wichtig ab der zweiten Seite. Somit kann der Kopf und die Fußzeile nicht überschrieben werden.
Es wäre schön, wenn der Kopf mit Logo bzw. Hintergrundbild (ganze Seite) für die nachfolgenden Seiten zur Verfügung stehen würde.
Dynamisch sich anpassende Linien geht schon, aber nicht über die Seitengrenzen hinweg. Da könnte die y Koordinate (y Anfang/ y Ende) helfen.

Kopf- Fußzeile über Freitexte auf jeder Seite
bei Platzierung zusätzlich noch erste und letzte Seite
Grafik auch auf jeder Seite (evtl. mehrere)
der dynamische Inhalt darf erst nach den oberen Elementen, die auf jeder Seite erscheinen kommen

Im GLE könnte beim Attributtyp Dokument außer dem Dateinamen und dem Vorschaubild auch die Dateigröße angezeigt werden.

Passwort ändern / Loginformular – Info über Art und Länge des Passwortes, ggf. frei konfigurierbar

Nachdem für Nutzer, NutzerID und Zeitstempel die Optionen insert, update, export vorhanden sind, besteht der Wunsch nach der Option delete.
Wenn der Datensatz gelöscht wird, soll stattdessen in die Felder mit der Option delete das Datum bzw. der Nutzer eingetragen werden.

Der Weg um Layer zu administrieren ist sehr lang: Layerverw./Layer anzeigen/aus Hunderten den richtigen raussuchen/Ändern ...
Gerade wenn man mehrere Layer vergleichen oder bearbeiten möchte ist es sehr mühselig. 
Viel einfacher wäre es, wenn Admins in der Kartenansicht im Layerkontextmenü den Menüpunkt "Eigenschaften" vorfinden würden und somit schnell und einfach zwischen den Layereinstellungen der einzelnen Layer wechseln könnten.
Der Zugriff auf den Attibuteditor, evtl. auch Style/Labeleditor könnte auch dort erfolgen. Im Prinzip wie in fast jedem DesktopGIS. 

in den Layeroptionen eine Option "Eigenschaften" hinzufügen, wenn die Stelle das darf
darunter verbergen sich Links "Layerdefinition, Attributeditor, Rechte, Styles"

Kann man sich perspektivisch eine Änderung des Umgangs mit nutzerspezifischen (WMS)-Diensten vorstellen? Die jetzige Wahlfreiheit von Anlassen oder Löschen gefällt mir nicht so gut. Nach TimeOut-Abmeldung sind die Layer sicher auch weg?
Admins könnten zwar immer auf Anfrage einen Dienst als Layer einbauen, aber wenn es die Möglichkeit gäbe, dass durch den Nutzer importierte WMS in einer Gruppe „Eigene WMS-Dienste“ erhalten blieben, auch wenn sie ausgestellt werden wäre das besser. Aufwand für Admins zur Layereinrichtung für vllt. nur einen einzigen Mitarbeiter würde entfallen und der Nutzer bekäme mehr Autonomie bei der Einrichtung seiner (WMS)Layer. Eigene Layer müssten dann über Layerkontextmenü entfernt werden können.
Danach muss sich wahrscheinlich noch die Frage klären wie der Nutzer auf einfache Weise die Darstellunsgreihenfolge seiner eigenen WMS-Layer ändern kann…


-ein Deaktivieren der Rollenlayer führt nicht mehr zum Löschen
- in den Layeroptionen gibt es stattdessen eine Option "entfernen"
- außerdem gibt es in den Legendenoptionen folgende Optionen:
"alle eigenen Importe entfernen"
"alle Suchergebnislayer entfernen"
- Rollenlayer in die Zeichenreihenfolgeanpassung aufnehmen

Es wäre hilfreich, wenn im Menü Editor die Zuordnung zu den Stellen (ähnlich wie im Layer-Editor) erfolgen könnte. 

Bislang ist er in den Optionen ganz gut versteckt - der "Zeitpunkt für historische Daten". Wünschenswert wäre, dass daraus eine Eingabe wird, die man z.B. über einen Menüpunkt oder über einen Link im Header o.ä. direkt aufrufen könnte.

als Menüpunkt (mit Button) umsetzen