Wunsch-Liste: Unterschied zwischen den Versionen

Version vom 23. Oktober 2006, 09:44 Uhr

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

zurück zur ToDo-Liste

erweiterte Suchfunktion nach Flurstücken

--SigridP 16:28, 19. Okt 2006 (CEST)In der Version 1.6.2 ist jetzt ein Mehrfach-ALB-Ausdruck möglich, der bei der Suche über die Karte und über Namens- und Adressensuche gut funktioniert. Jedoch ist bei Vorgabe bestimmter Flurstücke, die über die Karte nicht auswählbar sind (da ALK nicht flächendeckend vorhanden ist oder über den I-Button eine genaue Auswahl nicht möglich ist)eine gemeinsame Auflistung nicht möglich. Hier wäre es gut, wenn man über die Flurstückssuche mehrere Flurstücke auswählen und durch eine Suchabfrage diese gemeinsam anzeigen und ausdrucken könnte.

Layer- und Userauswahl im Stelleneditor

--Markus Hentschel 16:02, 17. Okt 2006 (CEST) Bei vielen Layern und vielen Usern ist es praktisch unmöglich, einen Layer bzw. einen User aus den jeweiligen Listen auszuwählen. Hier wäre es schön, wenn diese beiden Listen alphabetisch sortiert würden.

Anzeige der Verfügbarkeit von Diensten

--Markus Hentschel 11:15, 17. Okt 2006 (CEST) Bei als WMS oder WFS eingebundenen Layern wird einfach nichts angwezeigt, wenn der Dienst aus irgendwelchen Gründen gerade nicht zur Verfügung steht. Ich könnte mir vorstellen, dass man eine "Ampel" hinter solchen Themen anzeigt, die als WMS/WFS eingebunden sind. Grün, wenn der Dienst da ist, sonst rot. Im Hintergrund müsste kvwmap alle paar Minuten einen Request machen und darüber prüfen, ob der Dienst vorhanden ist.

Ausgabe Stand der ALB-Daten im ALB-Druck

--Heinz Schmidt 10:46, 10. Okt 2006 (CEST)
Damit der Stand der Fortführung der ALB-Daten ersichtlich ist, schlage ich vor unter der Zeile "Datum" im ALB-Druck den "Stand" auszugeben, der aus der tabelle "alb_fortfuehrung", Spalte "ffzeitraum_bis" aus der postGIS DB kommen sollte. Habe die Zeile jetzt schon in die alb.php eingefügt und trage das Datum nach der Fortführung manuell ein.

Die Ausgabe sieht so aus:

  Datum 10.10.2006 09
  Stand: 07.09.2006

--Markus Hentschel 14:21, 17. Okt 2006 (CEST) Dasselbe sollte auch in der Namenssuche und der Sachdatenanzeige (flurstuecksanzeige.php) stehen.

Großformatige Druckrahmen

--Heinz Schmidt 09:14, 10. Okt 2006 (CEST)
Es sollten auch großformatige Drucke (A2 bis A0) mit kvwmap über Druckrahmen zu erzeugen sein.
Gefordert wird das z.B. im Bereich der Liegenschaftsverwaltung.

--Markus Hentschel 11:11, 17. Okt 2006 (CEST) Das war bei der Entwicklung der Druckfunktionalität in Richtung ALK-konformer Druck nicht dabei, wir hatten uns bewußt auf A4 und A3 als Standardausgaben beschränkt. Ich weiß nicht, wie es mit der Performance ist, wenn man Drucke größer A3 erzeugt. Das sind dann unter Umständen doch ziemliche Klopse, die da durch die Leitungen wollen.

fehlende Eigentümerangaben im ALB-Auszug

--SigridP 12:48, 22. Sep 2006 (CEST)
Der im Original-ALB-Auszug zu den Privatpersonen angegebene Zusatz "GbR ......", "Erbengemeinschaft", "zu je 1/2 Anteil" usw. ist im kvwmap-Auszug nicht enthalten. Dieser ist jedoch lt. Aussagen der zuständigen Mitarbeiter unbedingt erforderlich. Beim Durchforsten der postgresql-DB habe ich diesen Eintrag in der tabelle alb_grundbuecher in der Spalte zusatz_eigentuemer entdeckt.

Flurstücksanzeige im Kartenausschnitt

--SigridP 11:26, 15. Aug 2006 (CEST)Bei Anzeige eines in der Flurstücksanzeige ausgewählten Flurstücks im Kartenausschnitt ist dieses nach Betätigen eines Buttons nicht mehr gesondert gekennzeichnet. Auch die Auflistung in der Legende ist dann verschwunden. Hier wäre es sinnvoll, die Kennzeichnung solange sichtbar zu lassen, bis sie durch gesonderten Befehl ausgeschaltet wird.

Desweiteren sollte es möglich sein, bei Auflistung mehrerer Flurstücke in der Flurstücksanzeige (z.B. nach Suche aller FS eines Eigentümers) diese gemeinsam in der Karte anzeigen zu lassen. Diese Funktionalität ist in der Bauauskunft bereits enthalten.

Fachschale Bauleitplanung

Bei der Veränderung von B-Pläne etc. soll den Gemeinden, als Träger der Bauleitplanung, die Möglichkeit gegeben werden, um die zu verändernden Stellen ein Polygon zu zeichnen und somit die betroffenen Stellen unkenntlich zu machen. Damit soll gewährleistet werden, dass die betroffenen Teile der Pläne als nicht aktuell gekennzeichnet werden und somit seitens der Kreisverwaltung keine Falschaussagen getroffen werden.

Verbesserung der Festpunktverwaltung

--Heinz Schmidt 11:01, 12. Jul 2006 (CEST)
-Die Festpunktverwaltung beinhaltet eine Funktion in einer Suchergebnisliste, einen Link anzuklicken und dann eine Vorschau auf die entsprechende Einmessungsskizze zu erhalten. Für diese Vorschau ist es erforderlich, dass die Skizze im PNG-Format vorliegt. Andere Dateiformate werden hierfür momentan nicht unterstützt.
Für recherchierte Festpunkte können die Einmessungsskizzen zu Aufträgen hinzugefügt werden. Hierfür ist es erforderlich, dass die Skizzen zusätzlich im TIFF-Format vorliegen.
Der Verbesserungsvorschlag geht dahin, dass die Einmessungskizzen zukünftig im PDF-Format von kvwmap verwaltet werden; für die Vorschau und für die Zusammenstellung von recherchierten Festpunkten. Eine redundante Ablage in PNG und TIFF würde damit entfallen. Eine dateiformat-unabhängige Verwaltung der Einmessungskizzen, wie z.B. bei der Rissverwaltung, wäre auch zu diskuttieren. Mir würde aber das PDF-Format ausreichen.

Dieser Vorschlag ist in dem Zusammenhang zu sehen, dass das LAIV den Kreisen im Lande z. Zt. die TP-Beschreibungen im qualitativ hochwertigen PDF-Dateien zur Verfügung stellt. Diese können in der Form in KVWMAP momentan leider nicht verarbeitet werden.

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

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.

mehrere Auszüge mit einem Druckbefehl

--SigridP 10:55, 15. Aug 2006 (CEST)Bei Auflistung mehrerer Flurstücke in der Flurstücksanzeige besteht der Wunsch, diese nach Wahl des Ausdruckes mit einem Befehl nacheinander auszudrucken.

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.

--Pkorduan 10:57, 19. Sep 2006 (CEST) Die Koordinaten werden ja auch unter dem Kartenfenster angezeigt und daneben der EPSG Code. Ich könnte mir vorstellen diese Angabe zu verlinken mit einer extra Info zu diesem Koordinatensystem. Die vollständige Bezeichnung und Datum etc. würde da ja platzmäßig nicht hinpassen.

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.