Version vom 23. Dezember 2009, 09:29 Uhr

Inhaltsverzeichnis

1 Version 1.6.9
2 Version 1.6.8
3 Version 1.6.7
4 Version 1.6.6
5 Version 1.6.5
6 Version 1.6.4
7 Version 1.6.3
8 Version 1.6.2
9 Version 1.6.1
10 Version 1.6.0
11 Version 1.5.9
12 Version 1.5.8
- 12.1 ALB-Anzeige
- 12.2 kvwmap-Hilfe
13 Version 1.5.7

Version 1.6.9

+ Spaltenbreite für 'symbolname' in Tablle 'styles' zu gering

--HolgerR 10:28, 14. Okt 2008 (CEST)
Bei der Umsetzung der Zeichenvorschrift aus der AG Web-GIS für die Darstellung der Liegenschaftskarte in kvwmap mittels der Definitionstabelle in MySQL ist mir aufgefallen, dass die Spaltenbreite für den Symbolnamen in der Tablle 'styles' zu gering ist, um z.B. den Symbolnamen 'mischwald_einzelne_nadelws' abzuspeichern. Um die Symbolnamen aus der Datei 'symbole.sym' 1:1 übernehmen zu können, ist die Breite auf 40 mit nachfolgendem SQL-Befehl zu vergrößern:

ALTER TABLE `styles` CHANGE `symbolname` `symbolname` VARCHAR( 40 ) CHARACTER SET latin1 COLLATE latin1_german1_ci DEFAULT NULL

+ Keine Möglichkeit 'minwidth' und 'maxwidth' in die Tabelle 'styles' einzugeben

--HolgerR 10:28, 14. Okt 2008 (CEST)
Die Werte 'minwidth' und 'maxwidth' für die Steuerung der Linienstärke können nicht in der Tabelle 'styles' eingegeben werden. Um die entsprechenden Felder der Tabelle hinzuzufügen, sind folgende SQL-Befehle für die MySQL-Datenbank auszuführen:

ALTER TABLE `styles` ADD `minwidth` INT( 11 ) DEFAULT NULL AFTER `width` ;
ALTER TABLE `styles` ADD `maxwidth` INT( 11 ) DEFAULT NULL AFTER `minwidth` ;

Damit die Werte auch an das Mapfile übertragen werden, sind in der Datei 'kvwmap.php' in der Funktion 'loadMap' folgende Korrekturen vorzunehmen:

Für 'minwidth':

alt

$style->minwidth = $dbStyle['minwidth']

neu

$style-> set('minwidth',$dbStyle['minwidth']);

Für 'maxwidth':

alt

$style->maxwidth = $dbStyle['maxwidth'];

neu

$style-> set('maxwidth',$dbStyle['maxwidth']);

+ Übergabe des Feldnames aus 'angleitem' an Mapdatei erfolgt nicht

--HolgerR 10:01, 14. Okt 2008 (CEST)
Für die Mapserverversion kleiner 5.0 erfolgt die Übergabe des Feldnamens mit den Winkelangaben aus dem Feld 'angleitem' und die Übergabe eines Winkelwertes aus dem Feld 'angle' aus der Tabelle 'styles' nicht.

Als Lösung schlage ich folgende Verfahrensweise vor. Die Datei Funktion 'loadMap' in der Datei kvwmap.php ist wie folgt zu editieren:

Löschen der Kommentartags /* ... */
Für die Einträge in dem Feld 'angle' ist die Zeile

$style->angle = (int)$dbStyle['angle'];

mit folgender Schreibweise

$style -> set('angle',$dbStyle['angle']);

zu ersetzen. Wenn in dem Feld 'angle' eine '0' steht, wird der Schlüssel nicht in die Mapdatei eingetragen. Bei 'angle' = 'NULL' erscheint in der Mapdatei der Eintrag ANGLE 360, die winkelrichtige Darstellung bei der Verwendung von 'angleitem' erfolgt troztdem.

Die Übergabe des Feldnamens mit den Winkelangaben aus dem Feld 'angleitem' erreicht man durch das Ersetzen der Zeile

$style->angleitem = $dbStyle['angleitem'];

mit dieser

$style -> set('angleitem',$dbStyle['angleitem']);

In diesem Feld muss entweder kein Eintrag in der Datenbank od. halt der Feldbezeichner eingetragen sein. Ansonsten kommt es zum Abbruch beim Laden der Mapdatei - der Bildschirm bleibt weiß. Also, irgendwelche Zahlen sind an dieser Stelle mit 'NULL' zu ersetzen.

Welche Anpassungen bei der Mapserverversion > 5.0 vorzunehmen sind weiß ich nicht. Hier wird der Feldbezeichner für das Feld mit den Winkeleinträgen zum Schlüsselwort 'angle' angegeben.

Bei dieser Gelegenheit kann dann auch gleich der Aufruf von 'maxsize' wie folgt korrigiert werden

$style -> set('maxsize',$dbStyle['maxsize']*$this->map_factor);

Und schließlich kann noch der Aufruf für 'width' ohne Berücksichtigung von 'map_factor' mit folgender Zeile ersetzt werden:

$style-> set('width',$dbStyle['width']);

+ Darstellung von CARTOLINE funktioniert nicht

--HolgerR 10:03, 7. Okt 2008 (CEST)
Wenn für die Ausgestaltung von Layern des Typs 'Polygon' in der symbole.sym für die Ausgestaltung der Linien der Type CARTOLINE definiert wird, werden diese nicht angezeigt.

Um sich die Linien dennoch anzeigen zu lassen, darf in der Tabelle 'styles' das Feld 'color' nicht belegt sein. Damit jedoch bei leerem 'color'-Feld nicht der Wert '0 0 0' in das Mapfile übertragen wird, ist noch in der class-Datei kvwmap.php die function 'loadclasses' wie folgt anzupassen:
alt

        $RGB=explode(" ",$dbStyle['color']);
        $style->color->setRGB($RGB[0],$RGB[1],$RGB[2]);
        $RGB=explode(" ",$dbStyle['outlinecolor']);
        $style->outlinecolor->setRGB($RGB[0],$RGB[1],$RGB[2]);

neu

        if ($dbStyle['color']!='') {
          $RGB=explode(" ",$dbStyle['color']);
          $style->color->setRGB($RGB[0],$RGB[1],$RGB[2]);
        }
        if ($dbStyle['outlinecolor']!='') {
          $RGB=explode(" ",$dbStyle['outlinecolor']);
          $style->outlinecolor->setRGB($RGB[0],$RGB[1],$RGB[2]);
        }

Für eine kantengeglättete Darstellung der Cartolines sind folgenden Anpassungen notwendig weiter.... Da die Berechnungen der Kantenglättung sehr intensiv sind, verlängert sich die Zeit für die Aufbereitung, Übertragung und Darstellung der Karte.

+ Kartenausschnitt nach Layersuche

--Markus Hentschel 10:54, 12. Sep 2008 (CEST) Wenn man in der Layersuche nach einem Datensatz sucht, dessen Geometrie außerhalb des max. Extents der Stelle liegt, dann zoomt kvwmap trotzdem dahin. Es müsste aber eine entsprechende Meldung kommen.

+ Ausrichtung Nordpfeil

--HolgerR 08:37, 30. Jul 2008 (CEST)
Der Nordpfeil wird in der Druckausgabe bei Angabe eines Drehwinkels nicht gedreht. Ich nutze PHP in der Version 4.3.10 mit der internen GD-Bibliothek.

--Rahn 09:36, 31. Jul 2008 (CEST) Der Nordpfeil wird direkt im PDF erzeugt, d.h. er hat nichts mit GD zu tun. Eigentlich sollte das funktionieren. Ist der Pfeil vielleicht Teil des Hintergrundbildes?

--HolgerR 09:52, 31. Jul 2008 (CEST) sri. Genau. Der Pfeil ist Teil des Hintergrundbildes. Ist alles schon eine Weile her, als ich die Druckvorlagen erzeugt hatte.

+ Flurstücksdatenanzeige| Aktualität der ALK-Daten

--Hschmidt 08:51, 21. Jul 2008 (CEST)
Bei der Anzeige der Flurstücksdaten wird die Aktualität der Flurstücksdaten offenbar aus der Tabelle edbsdatei geholt. Diese sollte aber aus der Tabelle edbsauftrag aus der Spalte auftaktu stammen. War das nicht schon mal so? Es wird erst versucht, das Datum aus der edbsauftrag zu holen und wenn das nicht da ist, aus der edbsdatei.

- labelangleitem unter Mapserver 5.0.2

--HolgerR 16:37, 17. Jul 2008 (CEST)
Die Hausnummern der Gebäude werden unter dem Mapserver 5.0.2 nicht entsprechend der Winkelangaben in PostgreSQL ausgerichtet. Kann es sein, dass bei der Änderung von Mapserver 4.x nach 5.x hinsichtlich von Labelangleitem diese nicht nach Mapscript portiert worden sind?

--Rahn 10:16, 18. Jul 2008 (CEST) Sieht ganz danach aus. Wenn man sich das erzeugte savemapfile.map ansieht, steht beim entsprechenden Layer bei ANGLE 0.000000. Scheint also so, als wenn das Labelangleitem nicht interpretiert wird.

--HolgerR 10:25, 18. Jul 2008 (CEST) Ja, im Prinzip wird Labelangleitem nicht mehr layerweit angewandt. Statt dessen kann ich in der Sektion Label dem Winkel einen Wert aus einer Tabelle übergeben: angle [winkel]. Mittels Mapscript kann man an angle aber nur Zahlen übergeben. Ich sehe hier 2 Möglichkeiten:

Mapscript dazu bringen, dass hier auch alphanumerische Angaben möglich sind
kvwmap so umstricken, dass gleich die entsprechenden numerischen Werte an angle übergeben werden

In 'kvwmap.php' wird an angle der Eintrag aus der mysql-Tabelle 'layer', hier 'winkel', richtig übertragen. Es ist halt nur keine Zahl, sondern der Feldbezeichner.

--Rahn 15:34, 18. Jul 2008 (CEST) Ich denke, es dauert nur noch eine Weile, dann geht das auch mit PHPMapscript. Die Variante den Winkel selber aus der Postgres-DB auszulesen ist glaube ich zu aufwendig.

--HolgerR 07:03, 21. Jul 2008 (CEST) Stefan, kannst du das Problem in die Bug-Liste zum PHP-Mapscript reinstellen oder steht das da schon drin? Ich habe noch nichts entsprechendes gefunden.

- PostgreSQL 8.3.x - WHERE mit unterschiedlichen Datentypen

--HolgerR 08:43, 11. Jul 2008 (CEST)
Ich habe gerade einen Server mit der aktuellsten PostgreSQL-Version (8.3.3) aufgesetzt. Hierbei gibt es jedoch Probleme bei Abfragen, in denen in der WHERE-Klausel Daten unterschiedlichen Typs verglichen werden, z.B. beim Flurstückslayer im pfad-Statement:

... 
FROM alknflst as alkf, alkobj_e_fla AS alko, alb_v_gemarkungen as gemkg 
WHERE alko.folie='001' AND alko.objnr = alkf.objnr AND gemkg.gemkgschl=alkf.gemkgschl

Der Gemarkungsschlüssel 'gemkgschl' aus der Tabelle 'alknflst' ist vom Typ character varying(6) und aus der Tabelle 'alb_v_gemarkungen' vom Typ integer. In PostgreSQL wird folgende Fehlerausschrift erzeugt:

ERROR:  operator does not exist: integer = character varying
LINE 1: ...1' AND alko.objnr = alkf.objnr AND gemkg.gemkgschl=alkf.gemk...
                                                             ^
HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.

********** Fehler **********

ERROR: operator does not exist: integer = character varying
SQL Status:42883
Hinweis:No operator matches the given name and argument type(s). You might need to add explicit type casts.
Zeichen:1513

Siehe hierzu auch die Versionshinweise von PostgreSQL zu Release-8.3 Hieraus ergeben sich nun m.E. 2 Möglichkeiten auf die Weiterentwicklung von PostgreSQL zu reagieren:

Überarbeiten der Datenbankstruktur und ev. Anpassen der SQL-Statements
Anpassen der SQL-Statements, in denen unterschiedlichen Dateitypen verglichen werden in der Form

gemkg.gemkgschl::text=alkf.gemkgschl::text

bzw. - SQL-konform

CAST(gemkg.gemkgschl AS text)=CAST(alkf.gemkgschl AS text)

Darüber hinaus sollte vorerst auf den Einsatz der Version 8.3.x von PostgreSQL verzichtet werden.

--Markus Hentschel 15:01, 29. Jan 2009 (CET) Bei vielen Layern und Abfragen kann alles beim Alten bleiben. Hier eine Sammlung der Abfragen, die geändert werden müssen: Geänderte SQL-Abfragen bei Upgrade auf PostgreSQL 8.3.x

+ Generischer Layereditor - Geometrie hinzufügen ohne Geometrie

--HolgerR 15:48, 9. Jul 2008 (CEST)
Wird zum Geometrie hinzufügen bzw. entfernen ein Layer ausgewählt, der nicht flächendeckend vorliegt, wird bei einem Klick in einen leeren Bereich des Layers in der Flächenanzeige folgender Fehler angezeigt:

<br><b>Fehler bei SQL Anweisung:<br>SELECT round(Area(GeomFromText('\'))::numeric, 2)<br></b>\

und die Bearbeitung wird abgebrochen.

- Generischer Layereditor - Geometrie hinzufügen - Fehler bei 'ORDER BY - Klausel' in Data

--HolgerR 15:48, 9. Jul 2008 (CEST)
Zur Darstellung der zeitlich richtigen Reihenfolge von Objekten machte es sich erforderlich, in der Layerdefinition eine Sortieranweisung für die Daten in der Form SELECT * FROM data WHERE objnr > 1 ORDER BY datum zu vereinbaren.

Wird dieser Layer im Generischen Layereditor ausgewählt, um Geometrie hinzuzufügen oder zu entfernen, wird in der Flächenanzeige folgender Fehler angezeigt:

 <br><b>Fehler bei SQL Anweisung:<br>SELECT round(Area(GeomFromText('\'))::numeric, 2)<br></b>\

Obiges SELECT-Statement in ein View gepackt, funktioniert. Nun soll ja nicht immer ein View vereinbart werden. Gibt es die Möglichkeit, solche Statements entsprechend umzusetzen?

+ Tabelle u_menues Spalte order

--HolgerR 09:47, 7. Jul 2008 (CEST)
In den Dateien 'mysql_install.sql' und 'mysql_update.sql' ist als neue Spalte für die Standardsortierung der Menüs die Spalte order eingefügt worden. Dies ist in SQL ein reserviertes Wort. Beim Ausführen der Dateien bekomme ich hier eine Fehlerausschrift und die Abarbeitung der SQL-Statements wird abgebrochen. Entweder müsste der Spaltenbezeichner in Anführungszeichen ( `bezeichner` ) gesetzt werden oder halt umbenannt werden.

--Rahn 09:58, 7. Jul 2008 (CEST) Aber die Spaltenbezeichnung steht doch in Hochkommas...?

# Hinzufügen einer neuen Spalte für die Sortierung der Menüs
ALTER TABLE `u_menues` ADD `order` INT( 11 ) NOT NULL DEFAULT '0';

CREATE TABLE u_menues (
 id int(11) NOT NULL auto_increment,
 `name` varchar(100) NOT NULL default ,
 `name_english_windows-1252` VARCHAR(100) CHARACTER SET cp1250 COLLATE cp1250_general_ci NULL,
 `name_vietnamese_utf-8` VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL,  
 links varchar(255) NOT NULL default ,
 obermenue int(11) NOT NULL default '0',
 menueebene tinyint(4) NOT NULL default '1',
 target varchar(10) default NULL,
 `order` INT(11) NOT NULL DEFAULT '0',
 PRIMARY KEY  (id)
) TYPE=MyISAM;

--HolgerR 10:06, 7. Jul 2008 (CEST)

So ist das i.O. :) Bei mir war order in der Datei 'mysql_install.sql' nicht in accent grave eingeschlossen, deshalb die Fehlermeldung.

+ Fehlermeldung wenn ein Nutzer keiner Stelle zugeordnet ist

--Hschmidt 10:02, 23. Jun 2008 (CEST)
Wenn ein Nutzer, der keiner Stelle zugeordnet ist, versucht sich einzuloggen kommt eine Fehlermeldung:

... Richten Sie mit phpMyAdmin in der kvwmap Datenbank eine Referenzkarte, ein Stelle, einen Benutzer und eine Rolle ein!(Tabellen referenzkarten, stelle, user, rolle)

Hier wäre es sinnvoll diesen Fall mit einer Meldung abzufangen, z.B. "Sie haben z. Zt. keinen Zugriff auf eine Arbeitsstelle, bitte wenden Sie sich an ihren Systemverwalter!" o.ä.
Kommt zwar selten vor, aber ...

+- Einfärbung gesuchter Objekte

--HolgerR 08:52, 23. Jun 2008 (CEST)
Ich hatte versucht die Layerbezeichnungen, Classes, Styles und Labels zu systematisieren und entsprechende ID's zuzuordnen. Dabei bin ich über den Integerwert von 2.147.483.647 für Classes, Styles und Labels gekommen.

Als Resultat dieser Wertüberschreitung wird das gesuchte Objekt nicht mehr gelb in der Karte dargestellt. Muss ich mit dieser Einschränkung leben und die ID-Werte wieder verringern oder gibt es Möglichkeiten, dieses zu umgehen?

--Rahn 13:38, 23. Jun 2008 (CEST) Man könnte den Datentyp der IDs anpassen. Entweder macht man aus dem INT ein UNSIGNED INT, dann hat man nochmal den Bereich bis 4.294.967.295 zur Verfügung. Oder man nimmt BIGINT, dann geht's bis maximal 18.446.744.073.709.551.615 (siehe MySQL-Dokumentation).

--HolgerR 13:56, 23. Jun 2008 (CEST) Das habe ich schon versucht, die IDs in classes, styles und rollenlayer haben den Typ BIGINT mit 12 Stellen. In der Tabelle 'rollenlayer' wird jedoch in der Spalte 'class_id' ein Wert unabhängig von der ID in der tabelle 'classes' inkrementell eingetragen. In der Tabelle 'u_styles2classes' werden in den Spalten 'class_id' und 'style_id' auch inkrementelle Werte eingetragen, die mit den Werten in den Tabellen 'classes' und 'styles' nicht übereinstimmen.

Könnte das vielleicht mit PHP und dem Betriebssystem zusammenhängen? (siehe PHP-Integer_Referenz).

--Rahn 14:26, 23. Jun 2008 (CEST) Es liegt wohl an der verwendeten mysql_insert_id() Funktion. Auf der Seite in der PHP-Dokumentation steht nämlich eine entsprechende Warnung.

+ Firefox 3 - Werkzeugleiste

--HolgerR 11:13, 20. Jun 2008 (CEST)
Seit vorgestern steht der Firefox 3 zum Download bereit. Erste Tests haben ergeben, dass die Werkzeugleiste nicht mehr so funktioniert wie gewohnt. Buttons, die eine Aktion auslösen, wie z.B. Gesamtansicht, funktionieren wie gehabt. Die anderen Funktionsbutton werden mit einem Anklicken nicht mehr aktiviert, der Focus springt vom gewünschten Button wieder auf den letzten aktiven Button zurück. Wird der Mauszeiger jedoch vom zu aktivierenden Button mit gedrückter linker Maustaste in das Kartenfenster gezogen, erhält dieser Button den Fokus und die Funktion kann wie gewohnt ausgeführt werden.

--Rahn 13:23, 23. Jun 2008 (CEST) Um den Fehler zu beheben, müssen in den Dateien SVG_map.php und SVG_druckausschnittswahl.php die Zeilen

<a xlink:href="">

und

</a>

gelöscht werden.

Das gleiche gilt für die Datei SVG_Utilities.php. Hier darf aber nicht die ganze Zeile

<a xlink:href="">';

gelöscht werden, das

';

muss stehen bleiben.

--Markus Hentschel 08:42, 25. Jun 2008 (CEST) Geht es dann noch mit Firefox 2 oder ist diese Änderung nur für die, die mit firefox 3 arbeiten?
--Rahn 09:58, 25. Jun 2008 (CEST) Nö, das sollte auch im Firefox 2 funktionieren.
--Markus Hentschel 10:37, 25. Jun 2008 (CEST) Jau, tuts.

+ Antraganzeige - Zugeordnete Festpunkte in KVZ Schreiben

--HolgerR 11:08, 19. Jun 2008 (CEST)
Wird in der Antragsanzeige 'Zugeordnete Festpunkte in KVZ Schreiben' ausgewählt, ohne einen Antrag auszuwählen, wird der Programmlauf abgebrochen. Um diesen Fehler abzufangen, sind die Dateien index.php und kvwmap.php wie folgt anzupassen:

index.php - case 'Antraganzeige_Festpunkte_in_KVZ_schreiben' durch folgende 4 Zeilen ersetzen:

  case 'Antraganzeige_Festpunkte_in_KVZ_schreiben' : {
    $GUI->festpunkteInKVZschreiben();
    $GUI->Antraege_Anzeigen();
  } break;

kvwmap.php - function festpunkteInKVZschreiben() mit nachfolgenden Code ersetzen

  function festpunkteInKVZschreiben() {
#19.06.2008, H.Riedel; Abfrage, ob Antrag ausgewaehlt wurde
    if ($this->formvars['antr_selected']=='') {
      $this->Fehlermeldung= '<br>Wählen Sie eine Antragsnummer aus!';
    }
    else {
      $festpunkte=new Festpunkte('',$this->pgdatabase);
      $ret=$festpunkte->createKVZdatei($this->formvars['antr_selected']);
      if ($ret[0]) {
        $this->Fehlermeldung=$ret[1];
      }
      else {
        $this->Meldung=$ret[1];
      }
    }
  }

+ Dokumentenrecherche über Individuelle Nummer oder Antragsnummer :-(

--Hschmidt 10:13, 11. Jun 2008 (CEST)
Die Dokumentenrecherche über Individuelle Nummer oder Antragsnummer funktioniert nur in Verbindung mit einem Such-Polygon ansonsten kommt kommt die Meldung:

Geben sie ein Polygon an.

Eine reine Suche nach Sachdaten ist nicht möglich.

--HolgerR 07:45, 30. Jul 2008 (CEST)

Im Snippet 'dokumenteneingabeformular.php' muss die Funktion 'save()' angepasst werden. Da muss irgenwie rein, dass nur bei der Suche nach 'Suchpolygon/-fenster' auf Vorhandensein eines Polygons getestet wird.

+ Notizen erstellen

--Varchmin 18:13, 10. Jun 2008 (CEST) Wenn man im Notizenformular eine Flächennotiz erstellen will, kommt beim klicken in die Karte mit dem Werkzeug "Polygon hinzufügen" folgender Laufzeitfehler in Microsoft JScrip:

'topt.document.GUI.lastcoordx' ist NULL oder kein Objekt line:601, column:2

--Rahn 08:56, 11. Jun 2008 (CEST) Um den Fehler zu beheben, müssen in der Datei SVG_polygon_xor_point.php nach der Zeile

<input name="last_doing" type="hidden" value="<? echo $this->formvars['last_doing']; ?>">

diese beiden Zeilen eingefügt werden:

<input name="lastcoordx" type="hidden" value="">
<input name="lastcoordy" type="hidden" value="">

--Varchmin 10:13, 11. Jun 2008 (CEST) Super! Problem behoben!

- vorherige Ansicht / naechste Ansicht im Kartenfenster

--Hschmidt 09:11, 9. Jun 2008 (CEST)
Die beiden Buttons "vorherige Ansicht / naechste Ansicht" im Kartenfenster funktionieren nicht mehr :-(

--Rahn 14:16, 9. Jun 2008 (CEST) Hmmm, bei mir tun sie's. Inwiefern äußert sich das? Passiert gar nichts, oder lädt die Seite neu und der Kartenausschnitt stimmt nicht?

+ Dokumentenrecherche über Polygon

--Hschmidt 14:50, 5. Jun 2008 (CEST)
Die Dokumentenrecherche über Polygon geht nicht mehr und in der Fehlerkonsole vom Firefox wird folgende Meldung abgelegt:

Fehler: top.document.GUI.lastcoordx has no properties Quelldatei: http://10.130.16.92/tmp/553264SVG_dokumentenformular.svg Zeile: 572

--Rahn 08:49, 6. Jun 2008 (CEST) Um den Fehler zu beheben, müssen in der Datei SVG_polygon_box_area.php nach der Zeile

<input name="last_doing" type="hidden" value="<? echo $this->formvars['last_doing']; ?>">

diese beiden Zeilen eingefügt werden:

<input name="lastcoordx" type="hidden" value="">
<input name="lastcoordy" type="hidden" value="">

--Hschmidt 09:04, 9. Jun 2008 (CEST)
so läufts :-) Danke!

+ GLE | nachträgliches Erfassen von Punktgeometrien

--Hschmidt 10:14, 3. Jun 2008 (CEST)
Das nachträgliche Erfassen von Geometrien im GLE ist bei Punktdaten schwierig.
Folgendes Beispiel: in einer Tabelle sind Sachdaten vorhanden und die Geometrie in Form eines Punktes soll nachträglich erfasst werden. Es wird im Kartenfenster der entsprechende Ausschnitt, wo der Punkt digitalisiert werden soll ausgewählt. Der Datensatz wird über die Layersuche selektiert und bei Aufruf der Geometriebearbeitung erscheint ein weisses Bild und der voreingestellte Kartenausschnitt wird verlassen.
Das gleiche Beispiel bei der Nacherfassung von Polygonen funktioniert jedoch.

- Filterverwaltung

--Hschmidt 15:13, 20. Mai 2008 (CEST)
Beim Versuch in der Filterverwaltung ein Polygon abzuspeichern kommt folgende Fehlermeldung:

Warning: pg_query() [function.pg-query]: Query failed: ERROR: unterminated quoted string at or near "'01060000205E0900000100000001030000000100000006000000B487CF006BD350413165AD8E10955641CC1976B573D350419A684A7517955641C05E73B97BD3504199AF72B0139556410F3333FB7AD35041D0AA63020E955641D6F0198670D350412C56C7140A955641B487CF006BD3504131, 2398)" at character 158 in /usr/local/httpd-2.2.3/htdocs/kvwmap-1.6.9/class/postgresql.php on line 3913

Fehler bei SQL Anweisung: SELECT geomfromtext('POLYGON((4410782.6 5919764.1, 4410876.4 5919764.1, 4410876.4 5919857.9, 4410782.6 5919857.9, 4410782.6 5919764.1))', 2398) && TRANSFORM('01060000205E0900000100000001030000000100000006000000B487CF006BD350413165AD8E10955641CC1976B573D350419A684A7517955641C05E73B97BD3504199AF72B0139556410F3333FB7AD35041D0AA63020E955641D6F0198670D350412C56C7140A955641B487CF006BD3504131, 2398)

Die gleiche Aktion läuft unter der Version 1.6.7 fehlerfrei. Bei einfachen Polygonen bis zu 4 Stützpunkten gibt es auch keinen Fehler.

Version 1.6.8

+ Hausnummernsortierung in Adresssuche

--Markus Hentschel 13:41, 30. Jun 2008 (CEST) In der Adresssuche werden die Hausnummern alphanummerisch sortiert, obwohl sie nummerisch sortiert sein sollten. Das war doch schon mal anders, oder?

+ Suchergebnis nach Flurstückssuche

--Markus Hentschel 11:25, 30. Jun 2008 (CEST) Wenn man nach einem Flurstück gesucht hat, erscheint es zweimal in der Gruppe Suchergebnis.

+ auseinandergezogene Menüs

--Certa 11:27, 13. Jun 2008 (CEST) Die Menüs auf der linken Seite werden auseinander gezogen, wenn die Seite sehr lang wird. Eigentlich müssten die Menüpunkte am oberen Rand der Seite bleiben.

+ Laufzeitfehlermeldung bei Koordinatenzoom

--Markus Hentschel 09:50, 28. Mai 2008 (CEST) Wenn man den Button Koordinatenzoom wählt und das Extrafenster anschließend wieder schließt, kommt eine Fehlermeldung "JScript Laufzeitfehler", die sich nicht wegklicken lässt.

--Rahn 11:24, 16. Jun 2008 (CEST) Um den Fehler zu beheben, muss in der Datei SVGvars_coordscript.php folgende Funktion ausgetauscht werden:

 function coords_input(){
 	if(scale < 0.01){
 		stellen = 2;
 	}
 	else if(scale < 0.1){
 			stellen = 1;
 	}
 	else{
 		stellen = 0;
 	}
 
 	mittex = format_number(mittex, stellen);
 	mittey = format_number(mittey, stellen);
 	coords1 = prompt("Geben Sie die gewünschten Koordinaten ein",mittex+" "+mittey);
 	if(coords1){
 		coords2 = coords1.split(" ");
 		if(!coords2[0] || !coords2[1]){
 			alert("Falsches Format");
 			return;
 		}
 		//coords[0] = (Number(coords[0])-minx)/scale;		Weltkoordinaten übergeben
 		//coords[1] = (maxy-Number(coords[1]))/scale;
 		document.GUI.INPUT_COORD.value = coords2[0]+","+coords2[1];
		document.GUI.CMD.value = "jump_coords";
 		document.GUI.submit();
 	}
 }

+ Mittelpunkt setzen mit Pan geht nur einmal

--Markus Hentschel 09:50, 28. Mai 2008 (CEST) Wenn man den Verschiebebutton auswählt und dann in die Karte klickt, wird der angeklickte Bildpunkt neuer Bildmittelpunkt. Das funktioniert allerdings nur beim ersten Mal, wenn man das noch mal macht, wird der Bildschirmausschnitt nicht verschoben.

+ CSV-Export Flurstücke

--Markus Hentschel 13:45, 29. Apr 2008 (CEST) Wenn man einen CSV-Export bei Flurstücken oder historischen Flurstücken macht, fehlen die Attribute status und nachfolger. Dafür wird die WKT-Geometrie in the_geom mit ausgegeben, was unnötig ist.

+ Geometrie-Editor - Geometrieübernahme

--HolgerR 09:13, 25. Apr 2008 (CEST) Im Geometrieeditor ist das Übernehmen von Geometrien nicht möglich. Nach Auswahl des Werkzeuges 'Geometrie hinzufügen' wird beim ersten Klick in die Karte im Feld 'Fläche' folgender Eintrag generiert:

 <br><b>Fehler bei SQL Anweisung:<br>SELECT round(Area(GeomFromText('\\'))::numeric, 2)<br></b>\

In der php-Logdatei werden folgende Einträge generiert:

[25-Apr-2008 09:16:34] PHP Warning:  pg_query(): Query failed: ERROR:  Invalid OGC WKT (too short)
CONTEXT:  SQL function "geomfromtext" statement 1 in /srv/www/htdocs/kvwmap/class/postgresql.php on line 3907
[25-Apr-2008 09:16:34] PHP Warning:  pg_query(): Query failed: ERROR:  Invalid OGC WKT (too short)
CONTEXT:  SQL function "geomfromtext" statement 1 in /srv/www/htdocs/kvwmap/class/postgresql.php on line 3907
[25-Apr-2008 09:16:35] PHP Warning:  pg_query(): Query failed: ERROR:  Invalid OGC WKT (too short)
CONTEXT:  SQL function "geomfromtext" statement 1 in /srv/www/htdocs/kvwmap/class/postgresql.php on line 3907

In der debug-Datei sind folgende Einträge erfolgt:

<br><br><b>Anwendungsfall go: spatial_processing</b>
<br><p>file:kvwmap class:db_mapObj->getlayerdatabase - Lesen des connection-Strings des Layers:<br>SELECT `connection` FROM layer WHERE Layer_ID = 630301
<br><br>Datenbankverbindung öffnen: Datenbank: kvwmap User: user Passwd: passwort
<br>Datenbank mit Connection_ID: Resource id #53 geöffnet.
<br><br><b>Fehler bei SQL Anweisung:<br>SELECT round(Area(GeomFromText('\\'))::numeric, 2)<br></b>
<br><br>MySQL Verbindung mit ID: Resource id #41 schließen.
<br><br>PostgreSQL Verbindung mit ID: Resource id #53 schließen.

Das Hinzufügen von Geometrien und die weitere Bearbeitung der bisherigen Geometrie ist anschließend nicht mehr möglich. Nach Betätigen des Button 'Polygon Löschen' wird der Eintrag aus dem Feld 'Fläche' gelöscht und die Geometrie kann über 'Polygon hinzufügen', 'Polygon ausschneiden' und 'Eckpunkte bearbeiten' hinzugefügt bzw. geändert werden. Ich nutze PostgreSQL 8.1.9 mit PostGIS in der Version 1.1.7 (USE_GEOS=1 USE_PROJ=1 USE_STATS=1), PHP Version 4.3.10, Proj 4.6.0, Geos 3.0.0, Mapserver 4.10.3

--Rahn 11:11, 25. Apr 2008 (CEST) Vielleicht ne dumme Frage, aber einen Geometrieabfragelayer hast Du auch ausgewählt, oder?

--HolgerR 12:56, 25. Apr 2008 (CEST) Stefan, wann ist ein Layer ein Geometrieabfragelayer. Darf die Geometrie aus mehreren Datenbanktabellen zusammengesetzt sein oder geht das nur über einen Layer/View, der in der 'geometry_columns' steht ? Der "klassische" Flurstückslayer geht bei mir nicht, jedoch ein Geometrielayer mit nur einer Tabelle in der DATA-Deklaration.

--Rahn 15:29, 25. Apr 2008 (CEST) Ein Geometrieabfragelayer kann auch auf mehrere Tabellen zugreifen. Wichtig ist, dass es unter allen Tabellen nur ein 'the_geom' gibt. Wenn es mehrere 'the_geom' Spalten gibt, muss man durch qualifizierte Bezeichner festlegen, welches 'the_geom' für die Geometrieabfrage verwendet werden soll. Beim Layer Flurstücke gibt es 2 'the_geom' (einmal in alkobj_e_fla und einmal in alkobj_t_pkt), deswegen muss man das Data-Statement anpassen: Klick

--HolgerR 13:18, 28. Apr 2008 (CEST) Ich habe den Flurstückslayer so wie unten beschrieben abgeändert ... leider ohne Erfolg :( Die Fehlermeldungen sind noch die gleichen.

--HolgerR 07:24, 30. Apr 2008 (CEST) Ich habe jetzt das DATA-Statement so weit runtergebrochen, dass da nur noch SELECT * FROM tabelle steht und dann funktioniert es. Sobald allerdings im SQL-Statement in der WHERE-Klausel auf einen Text bezug genommen wird, hier WHERE folie='001', dann kann ich die Geometrie von diesem Layer nicht mehr übernehmen. Integer in der WHERE-Klausel sind kein Problem. Es müsste m.E. an den Hochkommatas, mit denen der Text eingeschlossen ist liegen. Wird das ganze Statement in ein View gepackt und dann das View im DATA-Statement angesprochen, funktioniert es.

--Rahn 11:17, 30. Apr 2008 (CEST) Problem gelöst. Es lag hier dran.

+ Fehlermeldung bei Login-Fehler

--Hschmidt 10:39, 24. Apr 2008 (CEST)
Kein Fehler dieser Version, aber bei fehlerhaftem Login passiert einfach nichts :-( Wünschenswert wäre eine Fehlermeldung, sonst sind die Anwender oft verwirrt.

+ Nachweisverwaltung - Rechercheergebnis - Nachweise Löschen

--HolgerR 10:31, 22. Apr 2008 (CEST) Der Aufruf für die Anzeige des Löschbutton erfolgte bis zur Version 1.6.5 im Snippet 'nachweisanzeige.php' über:

<? if($this->Stelle->isFunctionAllowed('Nachweisloeschen')){ ?>

Seit der Version 1.6.6 lautet der Aufruf aber

<? if($this->Stelle->isFunctionAllowed('Nachweiseloeschen')){ ?>

Damit wird der Löschbutton nicht mehr angezeigt. In der Datei 'index.php' heißt die Funktion 'Nachweisloeschen', so ist sie auch in der MySQL-DB in der Tabelle 'u_funktionen' hinterlegt. Handelt es sich hierbei nur um einen Tippfehler im Snippet oder muss die Tabelle 'u_funktionen' um den Eintrag 'Nachweiseloeschen' erweitert werden?

--Rahn 11:32, 22. Apr 2008 (CEST) Das Problem hatten wir letztes Jahr schonmal: Klick. Aber offenbar gibt es immernoch Unterschiede in der Schreibweise zwischen der index.php in dem Snippet. Deshalb wird jetzt alles in "Nachweisloeschen" geändert.

In der index.php steht es ja schon so.
Dann muss es eine Funktion "Nachweisloeschen" geben, die den jeweiligen Stellen zugeordnet ist.
Und das Snippet muss angepasst werden, also in der oben genannten Zeile muss es "Nachweisloeschen" heißen.

--HolgerR 12:32, 22. Apr 2008 (CEST) Sri, das nächste Mal muss ich dann wohl doch intensiver die Bugliste studieren. Der Eintrag in der mysql_install_help.sql - Datei passt dann auch zum Vorschlag von Stefan.

+ Festpunkte Sachdatenanzeige - kein Sprung auf Punkt

--HolgerR 13:30, 21. Apr 2008 (CEST) Die Anzeige des Festpunkte im Kartenfenster aus der Sachdatenanzeige heraus funktioniert nicht. Dies gilt sowohl für den Aufruf der Sachdaten über die Festpunktsuche bzw. aus der Karte heraus. Beim Klick auf 'Anzeige: in Karte' wird lediglich die Karte mit der letzten Ausdehnung angezeigt. Ein Zentrieren auf den gewünschten Punkt erfolgt leider nicht.

Das Drücken des Button 'Festpunkte Anzeigen' zentriert auch nicht auf die recherchierten Punkte.

--HolgerR 17:14, 21. Apr 2008 (CEST) Nach Rücksprache mit Stefan hat sich herausgestellt, dass in unserer index.php zwischen case 'Sachdaten_Festpunkte Anzeigen' und case ' Festpunkte in Liste Anzeigen' folgender Eintrag fehlte:

 case 'Festpunkte Anzeigen' : {
   $GUI->festpunkteZeigen();
 } break;

+ Flächenmessung/Streckenmessung im IE

Damit man den Kartenausschnitt nach einer Flächen- oder Streckenmessung auch im Internet Explorer verschieben kann, muss in der Datei SVG_map.php vor die beiden Zeilen

length = world_pathx.length;

und

length = world_polypathx.length;

jeweils ein var davorgesetzt werden, also so:

var length = world_pathx.length;

und

var length = world_polypathx.length;

+ Druckvorschau | Fehlermeldung

--Hschmidt 14:57, 17. Apr 2008 (CEST)
Beim Versuch die Druckvorschau aus der Druckausschnittswahl zu aktivieren kommt folgende Fehlermeldung:

Fatal error: Property 'width' does not exist in this object. in /usr/local/httpd-2.2.3/htdocs/kvwmap-1.6.8/class/kvwmap.php on line 8371

--Hschmidt 14:33, 17. Jul 2008 (CEST)
Die Fehlermeldung wurde durch einen fehlerhaften Style zu einem Layer verursacht. In der Spalte "width" des Styles war ein Wert eingetragen. Lässt man die Spalte leer tritt der Fehler nicht auf. Hat aber nichts mit der kvwmap-Version zu tun :-)

+ Grundbuchblattsuche | Flurstücksdaten anzeigen

--Hschmidt 14:09, 17. Apr 2008 (CEST)
Aus dem Ergebnis der Grundbuchblattsuche funktioniert das "Flurstücksdaten anzeigen" nicht.

--Rahn 13:23, 18. Apr 2008 (CEST) Stimmt. Um den Fehler zu beheben, muss man im Snippet grundbuchblattanzeige.php die Zeile

<input name="go" type="hidden" value="">

aus dem if-Block rausnehmen und darüber, hinter den anderen hidden-Feldern wieder einfügen.

+ Stelle Wählen

--Hschmidt 12:54, 17. Apr 2008 (CEST)
Nach Auswahl der neuen Stelle und anschließendem betätigen des 'Start' - Buttons kommt die Meldung "Fehler beim Wechseln der Stelle. Prüfen Sie die Angaben.". Das Wechseln der Stelle funktioniert dann erst beim dritten Versuch die Stelle zu wechseln mit dem 'Start' - Button.
Das Einstellen einer anderen "Kartenprojektion (EPSG-Code)" funktioniert auch nicht.

--Rahn 12:05, 18. Apr 2008 (CEST) Kann es sein, dass hier dran liegt?

--Hschmidt 07:32, 21. Apr 2008 (CEST) Nee, diese Einstellungen sind o.K.. Unter Version 1.6.7 läuft es ja auch problemlos.

--Rahn 15:23, 21. Apr 2008 (CEST) Das Problem bei Herrn Schmidt war, dass die Kartenausdehnung der neuen Stelle (z.B. 4501025 6001653,4502834 6003462) nicht korrekt angezeigt wurde. Hier fehlte immer das erste Leerzeichen. Hat vielleicht noch jemand dasselbe Problem?

--HolgerR 16:51, 21. Apr 2008 (CEST) Jaha, bei uns tritt der Fehler auch auf. Log-Datei

--HolgerR 11:27, 30. Apr 2008 (CEST) Problem ist bei uns mit diesen Einstellungen hier gelöst.

+ Druckausschnitt wählen - Zoom

--HolgerR 10:46, 17. Apr 2008 (CEST) Die Button 'Hereinzoomen' und 'Herauszoomen' beim Wählen und Plazieren des Druckrahmens vergrößern bzw. verkleinern nicht den Kartenausschnitt. Es wird lediglich der Kartenausschnitt neu zentriert. In der Stellenauswahl ist im Feld 'Zoomfaktor' eine 2 eingetragen.

--Rahn 15:20, 21. Apr 2008 (CEST) Um den Fehler zu beheben, müssen folgende Funktionen im Snippet SVG_Druckausschnittswahl.php vor der Funktion focus_NAV() hinzugefügt werden:

 function zoomin(){
   doing = "zoomin"; 
   document.getElementById("canvas").setAttribute("cursor", "crosshair");
 }

 function zoomout(){
   doing = "zoomout";
   document.getElementById("canvas").setAttribute("cursor", "crosshair");
 }

 function zoomall(){
   document.getElementById("canvas").setAttribute("cursor", "wait");
   Full_Extent();
 }

 function recentre(){
   doing = "recentre";
   document.getElementById("canvas").setAttribute("cursor", "move");
 }

 function highlightbyid(id){
   document.getElementById("zoomin0").style.setProperty("fill","ghostwhite", "");
   document.getElementById("zoomout0").style.setProperty("fill","ghostwhite", "");
   document.getElementById("recentre0").style.setProperty("fill","ghostwhite", "");
   document.getElementById(id).style.setProperty("fill",highlighted, "");
 }

- Referenzkarte im Druck bei Nicht-Standard-SRS

--Markus Hentschel 09:09, 17. Apr 2008 (CEST) Wenn ich ein anderes als das für die Stelle als Standard definierte Koordinatensystem auswähle und anschließend die Karte drucke, bekomme ich kein oder ein falsch gelagertes Bild in der Referenzkarte - dort soll eine topographische Karte angezeigt werden, die als WMS eingebunden wird. Im entsprechenden Refmapfile steht in der connection nämlich die SRS drin und die verändert sich nicht, wenn der User das Koordinatensystem der Stelle wechselt.

+ Kartenbild anzeigen

Bei einigen scheint der Link "Kartenbild anzeigen" nicht zu funktionieren. Dazu die folgende Funktion in kvwmap.php austauschen:

 function showMapImage(){
   $this->loadMap('DataBase');
   $this->drawMap();
   $dateiname = explode('.', basename($this->img['hauptkarte']));
   if($dateiname[1] == 'jpg'){		
     $mainimage = imagecreatefromjpeg(IMAGEPATH.basename($this->img['hauptkarte']));
     $scaleimage = imagecreatefromjpeg(IMAGEPATH.basename($this->img['scalebar']));
   }
   elseif($dateiname[1] == 'png'){
     $mainimage = imagecreatefrompng(IMAGEPATH.basename($this->img['hauptkarte']));
     $scaleimage = imagecreatefrompng(IMAGEPATH.basename($this->img['scalebar']));
   }
   ImageCopy($mainimage, $scaleimage, imagesx($mainimage)-imagesx($scaleimage), imagesy($mainimage)-imagesy($scaleimage), 0, 0, imagesx($scaleimage), imagesy($scaleimage));
   ob_end_clean();
   ob_start("output_handler");
   ImagePNG($mainimage);
 }

- ALB-Einlesen - keine Auswertung der Kopfzeile

--HolgerR 07:45, 16. Apr 2008 (CEST) Beim Einlesen der WLDGe-Bezieherdaten wird die Kopfzeile nicht ausgewertet, egal, ob das Auswahlfeld deaktiviert od. aktiviert ist. Damit ist das mehrmalige Einlesen der selben WLDGe-Datei bzw. das Auslassen von WLDGe-Dateien möglich.

+ Zuweisen von Untermenüpunkten im InternetExplorer

Im Stelleneditor werden bei Benutzung des IE die Untermenüpunkte nicht angezeigt. Um die Funktion auch in diesem "Browser" nutzen zu können, muss folgendes im Snippet stelle_formular.php getan werden:

In der Funktion getsubmenues() muss die Zeile

ahah('<? echo URL.APPLVERSION; ?>index.php', 'go=getsubmenues&menue_id='+menue_id, new Array(document.GUI.submenues));

durch diese hier ersetzt werden:

ahah('<? echo URL.APPLVERSION; ?>index.php', 'go=getsubmenues&menue_id='+menue_id, new Array(document.getElementById('submenue_div')));

Außerdem müssen die Zeilen

<select name="submenues" size="4" multiple style="width:160px">
</select>

durch diese hier ersetzt werden:

 <div id="submenue_div">
   <select name="submenues" size="4" multiple style="width:160px">
   </select>
 </div>

Und dann muss in der Datei kvwmap.php folgende Funktion ersetzt werden:

 function get_sub_menues(){
    $this->Menue = new menue($this->user->rolle->language,$this->user->rolle->charset);
    $submenues = $this->Menue->getsubmenues($this->formvars['menue_id']);
    echo '<select name="submenues" size="4" multiple style="width:160px">';
    for($i=0; $i < count($submenues["Bezeichnung"]); $i++){
      echo '<option selected value="'.$submenues["ID"][$i].'">  --> '.$submenues["Bezeichnung"][$i].'</option>';
    }
    echo '</select>';
  }

+ Löschen von Stellen

Das Löschen von Stellen funktioniert nicht, weil der entsprechende Link in der Datei snippets/stellendaten.php nicht korrekt ist.

Dazu in der Zeile

<td>  <a href="javascript:Bestaetigung('index.php?go=Stelle_Loeschen&selected_stelle_id=<? echo $this->stellendaten['ID'][$i]; ?>&order=<? echo $this->formvars['order']; ?>','Wollen Sie diese Stelle wirklich löschen?')"><?php echo $this->strDelete; ?></a></td>

das go=Stelle_Loeschen

in go=Stelle_Löschen ändern.

+ Beim Speichern neuer Stellen passiert auch nichts

Das Problem ist das gleiche wie beim Anlegen von Layern (siehe nächster Bug). Hier muß die Datei stelle_formular.php angepasst werden.

+ Beim Speichern neuer Layer passiert nichts

--Pkorduan 10:54, 28. Mär 2008 (CET) Wenn man einen Layer anlegt und dann als neuen Layer abspeichern möchte, ohne dass man vorher einen existierenden Layer ausgewählt hatte zum Ändern und speichern, passiert nichts. Das Problem kommt auch durch die Umstellung auf Multilingualität. Das Hidden Formularfeld für go_plus ist innerhalb des if Blocks, der ausgeführt wird, wenn man einen vorhandenen Layer als neuen abspeichern möchte. Fehlerbehebung: In Datei Layer_Formular.php im Verzeichnis Snippets die Zeile:

<input type="hidden" name="go_plus" id="go_plus" value="">

vor die darüber stehende if Anweisung verschieben. Am besten direkt vor das Inputfeld

<input type="reset" value="<?php echo $this->strButtonBack; ?>">

+ Fehler bei der Grundbuchblattanzeige von der Namenssuche aus

--Andreas Thurm 15:51, 20. Mär 2008 (CET)In der Ergebnisliste der Namenssuche kann man über einen Link zur Anzeige des Grundbuchblattes gelangen. Das funktioniert aber nicht in jedem Fall. Oftmals zeigt er ein ganz anderes Grundbuch an, oder bringt einen Fehler, das es das gesuchte Grundbuch nicht gibt. In wenigen Fällen zeigt er auch das richtige Grundbuch an. Ich konnte noch kein System erkennen. Es gibt in der Ergebnisliste ja auch noch den Link zum Anzeigen der Flurstücke. Hier werden die richtigen Flurstücke (vom gewählten Grundbuch) angezeigt. Allerdings werden standardmäßig nur maximal 10 Flurstücke angezeigt. Das ist gekoppelt an die Anzeige der Treffer pro Seite. Ist das so gewollt?

--Rahn 15:59, 15. Apr 2008 (CEST)

Zum Beheben des Fehlers im Snippet namensuchform.php die beiden Zeilen

 <td align="center"><a href="javascript:grundbuchsuche(<?php echo $this->namen[$i]['bezirk'].','.$this->namen[$i]['blatt']; ?>);"><?php echo $this->namen[$i]['bezirk']; ?></a></td>
 <td align="center"><a href="javascript:grundbuchsuche(<?php echo $this->namen[$i]['bezirk'].','.$this->namen[$i]['blatt']; ?>);"><?php echo $this->namen[$i]['blatt']; ?></a></td>

durch diese hier ersetzen:

 <td align="center"><a href="javascript:grundbuchsuche(<?php echo '\''.$this->namen[$i]['bezirk'].'\',\''.$this->namen[$i]['blatt'].'\''; ?>);"><?php echo $this->namen[$i]['bezirk']; ?></a></td>
 <td align="center"><a href="javascript:grundbuchsuche(<?php echo '\''.$this->namen[$i]['bezirk'].'\',\''.$this->namen[$i]['blatt'].'\''; ?>);"><?php echo $this->namen[$i]['blatt']; ?></a></td>

+ Benutzer anlegen und bearbeiten

In den Nutzereditor haben sich 2 kleine Fehler eingeschlichen, die aber dazu führen, dass man keinen neuen Benutzer mehr anlegen und vorhandene nicht bearbeiten kann. Um die Fehler zu beheben, muss im Snippet userdaten_formular.php die Zeile

<input type="button" name="dummy" value="<?php echo $this->strSave; ?>" onclick="submitWithValue('GUI','go_plus','aendern')"><?php

durch diese hier ersetzt werden:

<input type="button" name="dummy" value="<?php echo $this->strSave; ?>" onclick="submitWithValue('GUI','go_plus','Ändern')"> <?php

und diese Zeile

?><input type="button" name="dummy" value="<?php echo $strButtonSaveAs; ?>" onclick="submitWithValue('GUI','go_plus','neu_eintragen')">

durch diese hier ersetzt werden:

?><input type="button" name="dummy" value="<?php echo $strButtonSaveAs; ?>" onclick="submitWithValue('GUI','go_plus','Als neuen Nutzer eintragen')">

Version 1.6.7

+ postgis_install.sql - fp_punkte2 - gist

--HolgerR 12:53, 11. Mär 2008 (CET) Im SQL-Statement hat sich ein kleiner Fehler eingeschlichen. Das Statement zur Erzeugung des Geo-Index muss wie folgt heissen:

CREATE INDEX fp_punkte2_the_geom_gist ON fp_punkte2 USING GIST (the_geom GIST_GEOMETRY_OPS);

- Anzeige der Flurstücke bei der Namenssuche

--Andreas Thurm 11:13, 26. Feb 2008 (CET) In der Ergebnisliste der Namenssuche werden die einzelnen gefundenen Grundbuchblätter aufgelistet. Der Link "anzeigen" in der Spalte Flurstücke suggeriert, das hier die Flurstücke des betreffenden Grundbuches angezeigt werden. Es werden hier aber alle Flurstücke für den betreffenden Eigentümer angezeigt (Funktion: Suche_flurstueck_zu _namen mit übergebener Namensnummer). Es erfogt keine Beschränkung auf das Grundbuchblatt. Das führt an dieser Stelle zu Missverständnissen. Wenn der Haken "Flurstücke anzeigen" gesetzt ist, bekommt man ebenfalls eine fehlerhafte Auflistung.

--Rahn 11:37, 11. Mär 2008 (CET) Das stimmt, theoretisch müßte der Link "anzeigen" eigentlich nur die Flurstücke des jeweiligen Grundbuchsblattes anzeigen. Ich kann mich aber erinnern, dass damals eine Funktion gewünscht war, die alle Flurstücke zu einem Namen liefert, deshalb wurde sie so implementiert. Vielleicht sollten wir nochmal diskutieren, was der Link nun bewirken soll. Wie gesagt, rein logisch betrachtet, dürften nur die Flurstücke des jweiligen Grundbuchblattes angezeigt werden.

+ Gemarkungsauswahl bei der Namenssuche

--Andreas Thurm 09:42, 26. Feb 2008 (CET) Wenn man in der Namenssuche keine Gemarkung angibt, so wird die Suche auch dementsprechend gestartet. Man erhält die ersten 10 Treffer. Will man dann weiter suchen, so ist das Eingabefeld mit der Gemarkung nicht mehr leer. Es steht die alphabetisch letzte Gemarkung drin. Und das wird auch bei der Weiter-Suche so berücksichtigt. Will am nalso blättern, so muss man jedesmal dieses Feld korrigieren und es wieder auf "-Auswahl-" stellen.

- Bugs in der Nachweiserfassung

--Markus Hentschel 12:31, 20. Feb 2008 (CET)

Arbeiten zwei User in der Nachweiserfassung und ändern beide in derselben Sekunde das Kartenbild, überschreibt der eine das Bild des anderen. --Rahn 14:22, 20. Feb 2008 (CET) behoben
Ab und zu wird kein (blau gefülltes) Polygon am Bildschirm erzeugt, sondern es erscheint nur der rote Rahmen. Das lässt sich speichern, allerdings wird die Bild-Datei mit 0 KB gespeichert. Ursache unbekannt.
Bei kombiniertem Zoomen/Pannen während des Zeichnens geht das Polygon verloren.
Ab und zu kommt eine XML-Fehlermeldung anstelle der Karte. Ursache unbekannt. Datei:xml-fehler nachweiserfassung.png
Wenn es einen Fehler beim Speichern gab, wird immer die Bild-Datei mit 0 KB auf dem Server gespeichert. Es müsste nichts gespeichert werden.

+ Lagebezeichnung im ALB-Ausdruck

--Markus Hentschel 13:31, 14. Feb 2008 (CET)

Hat die Lagebezeichnung eines Flurstücks im ALB mehrere Hausnummern, weden diese momentan alphanumerisch und nicht numerisch sortiert: aus "1, 2, 3, 10" wird "1, 10, 2, 3". Die Hausnummern sollten aber numerisch sortiert bleiben.
Gibt es sehr viele Hausnummern, wird momentan über den Rand des Dokuments hinaus geschrieben, d.h. man kann den Rest der Hausnummern nicht mehr lesen. Hier müssten Zeilenumbrüche erfolgen, wobei die jeweils nächste Zeile linksbündig dort anfangen müsste, wo in der ersten Zeile der Lagebezeichnung der Straßenname anfängt (nicht der Straßenschlüssel!).

+ Time-Attribut bei Geometrieänderung

--Markus Hentschel 13:16, 14. Feb 2008 (CET) Time-Attributfelder müssen auch dann aktualisiert werden, wenn etwas an der Geometrie eines Objektes geändert wird.

== + Festpunktverwaltung - Feldlänge 'tex' == --HolgerR 14:02, 13. Feb 2008 (CET)

Die Feldlänge in den Tabellen 'fp_punkte' und 'fp_punkte_temp' für die Abspeicherung des Datenelementes 'Text der Bemerkung' (TEX) ist nur 15 Zeichen lang. Laut Punktdateierlass M-V sind jedoch 18 Zeichen zulässig. Abhilfe schaffen hier folgende beiden SQL-Anweisungen:

ALTER TABLE fp_punkte_temp ALTER tex TYPE character varying(18);
ALTER TABLE fp_punkte ALTER tex TYPE character varying(18);

+ Flächenanzeige im Polygoneditor

Wenn man im Polygoneditor das Werkzeug zum Verschieben der Eckpunkte benutzt, wird die Flächenangabe nicht aktualisiert. Damit sie das tut, muss in SVG_Utilities.php in der Funktion end_vertex_move() am Ende des if-Blocks die Zeile

polygonarea();

eingefügt werden.

+ Platzhalter in der Namenssuche

--Markus Hentschel 09:09, 1. Feb 2008 (CET) In der Namenssuche steht ein gelb umrandeter Text, den vermutlich noch nie einer genauer durchgelesen hat, obwohl er von Anfang an nicht richtig war. Dort steht:

"Zur nicht exakten Suche geben Sie den Platzhalter % ein. z.B. erhalten Sie Angermeier und Neumeier mit der Eingabe %meier"

Das stimmt nicht, denn Angermeier und Neumeier erhält man auch durch die einfache Eingabe von meier. Mein Vorschlag:

"Geben Sie den Platzhalter "%" ein (z.B. "me%er"), wenn an der Stelle beliebige und beliebig viele Zeichen stehen dürfen. Geben Sie den Platzhalter "_" ein (z.B. "me_er"), wenn an der Stelle ein beliebiges Zeichen stehen darf."

Das Ganze vielleicht auch als Tooltipp hinter einem Info-Symbol, wie beim letzten Anwendertreffen besprochen.

+ weitere Treffer anzeigen nach CSV-Export

--Markus Hentschel 09:45, 25. Jan 2008 (CET) Wenn man im GLE eine Trefferliste hat mit mehr Treffern, als MAXQUERYROWS erlaubt, dann kann man blättern. Wenn man einen CSV-Export durchführt, lässt sich jedoch nicht mehr blättern. Der Klick auf "weiter" öffnet nur wieder die CSV-Datei.

+ Fehler beim Anzeigen von ALB-Auszügen für alle Flurstücke

--FrankGiese 11:12, 21. Jan 2008 (CET)

Bei einigen Nutzern (nicht bei allen Nutzern), die mit dem Microsoft Internet Explorer arbeiten und sich ALB-Auszüge (20,25,30,35) für alle ausgewählte Flurstücke aufrufen, öffnet sich ein neues Fenster (Acrobat Reader) und der Auszug wird in der Größe von 213% dargestellt. Es gibt keine Möglichkeit die Fenstergröße anzupassen, weil die Schaltfläche minimieren deaktiviert ist. Setzt man den Maßstab herab hat man nur den Erfolg, dass der Ausschnitt verkleinert dargestellt wird. Die Ausdehnung des Fensters bleibt aber gleich. In der Version 1.6.6 gab es dieses Problem nicht. Auch beim Aufruf der ALB-Anzeige für nur ein Flurstück funktioniert es in der Version 1.6.7 tadellos.
- --Markus Hentschel 11:51, 21. Jan 2008 (CET) Diesen Unterschied habe ich auch. Irgendwelche fehlenden/falschen Dateiheader? Die "Start"-Vergrößerung des Dokuments kann man jedoch beeinflussen, indem man (beim Acrobat Reader 7) auf "Bearbeiten" - "Grundeinstellungen..." geht und dort bei Seitenanzeige die sog. Standardvergrößerung verändert - z.B. auf Fenstergröße. Das muss allerdings auf jedem Rechner einzeln gemacht werden.
  - --FrankGiese 12:42, 21. Jan 2008 (CET) Danke Markus, aber das führte bei uns leider nicht zum Erfolg.
    - --Rahn 13:56, 1. Feb 2008 (CET) Versucht mal in der Flurstuecke_custom.php in folgender Zeile die Breite und Höhe runter zu setzen, also z.B. auf width=1024,height=768

window.open(url, "CSVExport", "toolbar=yes,status=yes,menubar=yes,width=2000,height=2000");

--Markus Hentschel 07:05, 4. Feb 2008 (CET) Gibts nicht sowas wie screen.availWidth und screen.availHeight?

--Rahn 14:51, 4. Feb 2008 (CET) Gibts! :

window.open(url, "CSVExport", "toolbar=yes,status=yes,menubar=yes,width="+self.screen.width+",height="+self.screen.height);

+ Fehler in der Nachweisrecherche und im Punkteditor

Durch die neue Funktion zum Bearbeiten von Polygonpunkten tritt im Nachweisrechercheformular und im Punkteditor ein Fehler auf. Um den Fehler zu beheben, muss in den Dateien SVG_polygon_box_area.php und SVG_point.php folgende Zeile

<input name="vertex_edit" type="hidden" value="<?php echo $this->formvars['vertex_edit']; ?>">

an den Abschnitt mit den ganzen input-Feldern angehängt werden. In SVG_polygon_box_area.php muss nach der Zeile

$svg .= $boxbuttons;

außerdem noch die Zeile

$svg .= $vertex_edit_buittons;

angehängt werden.

Analog zur Datei SVG_polygon_box_area.php müssen auch die Dateien SVG_polygon_xor_point.php und SVG_polygon_and_point.php angepasst werden.

- Namenssuche | Suchen mit Entertaste

--Markus Hentschel 14:46, 14. Jan 2008 (CET)

Wenn man in der Namenssuche ist und z.B. einen Namen eingegeben hat, dann kann man nicht mit [Enter] die Suche starten. Die Entertaste bringt einen vielmehr wieder zur Karte zurück. Ist das gewollt oder ein Bug?

+ Adressänderungstabelle bereinigen

Bei einigen PostgreSQL-Versionen kann es zu Problemen kommen, wenn man versucht die Tabelle alb_g_namen_temp zu bereinigen. Um den Fehler zu beheben, muss folgende Funktion in esaf.php ausgetauscht werden:

function delete_old_entries(){
   $sql = "DELETE FROM alb_g_namen_temp ";
   if(POSTGRESVERSION >= '810'){
     $sql.=" USING alb_g_namen ";
   }
   $sql.= "WHERE ((alb_g_namen_temp.name1 IS NULL AND (alb_g_namen.name1 IS NULL OR alb_g_namen.name1 = '')) OR alb_g_namen_temp.name1 = alb_g_namen.name1)"; 
   $sql.= "AND ((alb_g_namen_temp.name2 IS NULL AND (alb_g_namen.name2 IS NULL OR alb_g_namen.name2 = '')) OR alb_g_namen_temp.name2 = alb_g_namen.name2)"; 
   $sql.= "AND ((alb_g_namen_temp.neu_name3 IS NULL AND (alb_g_namen.name3 IS NULL OR alb_g_namen.name3 = '')) OR alb_g_namen_temp.neu_name3 = alb_g_namen.name3)"; 
   $sql.= "AND ((alb_g_namen_temp.neu_name4 IS NULL AND (alb_g_namen.name4 IS NULL OR alb_g_namen.name4 = '')) OR alb_g_namen_temp.neu_name4 = alb_g_namen.name4)";
   $ret = $this->database->execSQL($sql, 4, 0);
 }

Version 1.6.6

- Fehler in Notizkategorienverwaltung

--Hschmidt 15:36, 8. Jan 2008 (CET)
Notizen können in allen Stellen gelesen werden, obwohl in der Notizkategorienverwaltung das Recht "lesen" für die Notiz-Kategorie nicht gesetzt ist.

+ Feld Wert in der Filterverwaltung muss Typ 'text' sein

--Markus Hentschel 11:38, 14. Dez 2007 (CET) Filterausdrücke können durchaus länger als 255 Zeichen sein. Deswegen müssen die Eingabefelder des Werts in der Filterverwaltung beliebig lange Einträge zulassen.

+ als neuer Druckrahmen speichern | Ref.-Mapfile

--Markus Hentschel 15:07, 5. Dez 2007 (CET) Wenn man von einem vorhandenen Druckrahmen als neuen Druckrahmen speichert, wird der Eintrag zum Referenzkartenmapfile nicht kopiert.

+ OID in Hochkomma

--Markus Hentschel 11:33, 3. Dez 2007 (CET)
In polygoneditor.php muss die vierte Zeile der function zoomTopolygon() geändert werden:

 function zoomTopolygon($oid, $tablename, $border) {
   ...
   $sql.= " FROM ".$tablename." WHERE oid = '".$oid."';";
   ...

In kvwmap.php muss in der function sachdaten_speichern() die Zeile mit "WHERE oid =" geändert werden:

...        
if($attributname != 'oid'){
  if($this->formvars[$form_fields[$i]] == ){
     $sql = "UPDATE ".$tablename." SET ".$attributname." = NULL WHERE oid = '".$oid."';";
  }
  else{
     $sql = "UPDATE ".$tablename." SET ".$attributname." = '".$this->formvars[$form_fields[$i]]."' WHERE oid = '".$oid."';";
...

+ Nachweiserfassung/-recherche | Länge von Stammnummer und Blattnummer

--Markus Hentschel 09:38, 3. Dez 2007 (CET)
In der Nachweisdokumenteingabe muss die Zeichenlänge der Blattnummer variabel sein. Dazu muss in der config.php ein neuer Parameter hinzukommen:

# Erlaubte maximale Länge der Blattnummer in der Fachschale Nachweisverwaltung
define('BLATTNUMMERMAXLENGTH',4);

In der Datei dokumenteneingabeformular.php muss es dann entsprechend heißen:

<td colspan="2">Blattnummer:
  <input name="Blattnr" type="text" value="<?php echo $this->formvars['Blattnr']; ?>" size="<?php echo BLATTNUMMERMAXLENGTH; ?>" maxlength="<?php echo BLATTNUMMERMAXLENGTH; ?>">
 </td>

In der Nachweisdokumentsuche fehlt die Variable STAMMNUMMERMAXLENGTH. In der Datei dokumentenabfrageformular.php muss es richtig heißen:

<td colspan="2">          Stammnummer<br>
  <input type="text" name="suchstammnr" value="<?php echo $this->formvars['suchstammnr']; ?>" size="<?php echo STAMMNUMMERMAXLENGTH; ?>" maxlength="<?php echo STAMMNUMMERMAXLENGTH; ?>">
 </td>

In der Datenbank ist in der Tabelle n_nachweise das Attribut stammnr varchar(8). Es sollte vielleicht - genau wie das Attribut blattnummer - nur varchar sein.

--Markus Hentschel 10:51, 6. Dez 2007 (CET) In der Datei nachweisanzeige.php muss die Variable BLATTNUMMERMAXLENGTH ebenfalls eingetragen werden:

<td><div align="center"><?php echo $this->formvars['blattnummer']=str_pad(intval($this->nachweis->Dokumente[$i]['blattnummer']),BLATTNUMMERMAXLENGTH,'0',STR_PAD_LEFT); ?></div></td>

- Gemarkungsauswahl in der Namenssuche

--Markus Hentschel 12:48, 26. Okt 2007 (CEST)
Wenn man in der Namenssuche eine Recherche durchgeführt hat, wird anschließend die letzte der auswählbaren Gemarkungen im Feld "Gemarkung(Gemeinde)" angezeigt. Das ist bei verschiedenen Stellen der Fall, wobei ich kein Muster erkennen kann. Bin ratlos.

+ Notizen | Fehlermeldung Notizenformular

--Hschmidt 11:42, 24. Okt 2007 (CEST)
Wenn man im Notizenformular die Kategorien bearbeiten will und man über die Stelle nicht das Recht der Funktion "kategorienverwaltung" hat kommt die Fehlermeldung

Fatal error: Cannot access empty property in /usr/local/httpd-2.2.3/htdocs/kvwmap-1.6.6/index.php on line 672

Dieses sollte durch die übliche Meldung dass man nicht das entsprechende Recht besitzt abgefangen werden.

- Stellenverwaltung | Stelle kopieren

--Hschmidt 11:32, 16. Okt 2007 (CEST)
Beim Kopieren einer Stelle über die Stellenverwaltung mit "Als neue Stelle eintragen" werden die Layer-Werte für "transparency" nicht mit übernommen, was sinnvoll wäre.

+ Shape-Export

--Markus Hentschel 14:52, 15. Okt 2007 (CEST) Beim Auswählen einiger Layer im Shape-Export kommt eine Fehlermeldung, die ein zertrümmertes SQL anmeckert. Warum nur bei einigen, weiß ich nicht.

Der Fehler tritt bei den Layern auf, die keine Where-Klausel im Data-Statement haben. Zum Beheben also entweder where 1=1 hinten ran hängen oder in postgresql.php in der Funktion eliminate_star() den else-Zweig:

else{
   $whereposition = strpos(strtolower($query), 'where');
   $withoutwhere = substr($query, 0, $whereposition);
   $fromposition = strpos(strtolower($withoutwhere), 'from');
  }

durch den hier ersetzen:

else{
   $whereposition = strpos(strtolower($query), 'where');
   if($whereposition){
    $withoutwhere = substr($query, 0, $whereposition);
   }
   else{
    $withoutwhere = $query;
   }
   $fromposition = strpos(strtolower($withoutwhere), 'from');
  }

- Generischer Layereditor (GLE)

--Hschmidt 08:38, 7. Dez 2007 (CET)

Nachträgliches Erfassen von Geometrien unmöglich.

Wenn man im Layereditor einen Datenbestand bearbeiten will, den man z.B. von einer csv-Datei eingelesen hat und der noch keine Geometrie enthält, ist das nachträgliche Erfassen der Geometrie (Polygon) nicht möglich, obwohl die Geometriespalte vorhanden ist und in der Rechteverwaltung die Geometrie auf "editieren" gestellt wurde.

--Rahn 11:35, 7. Dez 2007 (CET) Liegt das vielleicht daran, dass die Tabelle nicht in geometry_columns eingetragen ist?
--Hschmidt 07:09, 11. Dez 2007 (CET)Stimmt, das wars! Beim Einlesen über eine CSV-Datei wird kein Eintrag in die geometry_colums gemacht. Das habe ich mit einem Insert nachgeholt:-)

--Reißland 14:08, 15. Okt 2007 (CEST)

folgende Kleinigkeiten sind mir beim Arbeiten mit dem GLE in 1.6.5 aufgefallen. Aus Zeitmangel habe ich nicht getestet ob alle in 1.6.6 schon behoben sind. Sollte das der Fall sein, bitte ich die Hinweise zu ignorieren.

Enthalten Tabellen ein CONSTRAINT das ein Komma beinhaltet (RFW1,RFW2) wird dieses nicht ordnungsgemäß ins Auswahlfeld des GLE übernommen.
Besteht ein CONSTRAINT aus Zahlenwerten wird es im Attributeditor nicht automatisch als Auswahlfeld markiert.
Enthalten Tabellen Attribute mit Anführungszeichen (Wohngruppe "Sonnenschein") wird das Attribut im GLE vor dem Anführungszeichen abgeschnitten (Wohngruppe). Einfache Anführungszeichen funktionieren zwar, führen aber bei der Datenaktualisierung zu einer Fehlermeldung.
Ist eine Tabellenspalte mit einem NOT NULL CONTRAINT versehen, erscheint im GLE im Auswahlfeld trotz allem eine Leerzeile. Bei Auswahl dieser Leerzeile kommt beim Abspeichern zwar eine Fehlermeldung, besser wäre aber, wenn die Leerzeile gar nicht vorhanden wäre.

--Rahn 14:16, 26. Okt 2007 (CEST)

Bei der Eingabe eines neuen Datensatzes (go=neuer_Layer_Datensatz) werden die bereits eingegebenen Attribute wieder gelöscht, wenn der Bearbeiter zur Geometrieeingabe im Kartenfenster zoomt.
--Markus Hentschel 11:39, 25. Okt 2007 (CEST) Bei der Eingabe eines neuen Datensatzes (go=neuer_Layer_Datensatz) werden die bereits eingegebenen Attribute auch wieder gelöscht, wenn der Bearbeiter erst nach der Eingabe einen Geometrieabfragelayer auswählt. Der Bearbeiter müsste gezwungen werden, ERST alle notwendigen Einstellungen zu tätigen, BEVOR er Sachdaten eingibt.

</Fehler behoben>

- Lagebezeichnung im ALB-Ausdruck

--Markus Hentschel 10:58, 15. Aug 2007 (CEST)

Hat die Lagebezeichnung eines Flurstücks im ALB mehrere Hausnummern, weden diese momentan alphanumerisch und nicht numerisch sortiert: aus "1, 2, 3, 10" wird "1, 10, 2, 3". Die Hausnummern sollten aber numerisch sortiert bleiben.
Gibt es sehr viele Hausnummern, wird momentan über den Rand des Dokuments hinaus geschrieben, d.h. man kann den Rest der Hausnummern nicht mehr lesen. Hier müssten Zeilenumbrüche erfolgen, wobei die jeweils nächste Zeile linksbündig dort anfangen müsste, wo in der ersten Zeile der Lagebezeichnung der Straßenname anfängt (nicht der Straßenschlüssel!).

+ Layernamen mit Sonderzeichen im Shape-Export

--Markus Hentschel 12:36, 15. Okt 2007 (CEST) Bei Layernamen, die Sonderzeichen enthalten (z.B. Leerzeichen) kommt es zu Fehlern beim Herunterladen aus dem Shape-Export heraus. Die Sonderzeichen müssten im Layernamen aufgelöst werden, z.B. Unterstrich statt Leerzeichen.

+ Anzeige der Namensnummern im ALB-Auszug 35

--Andreas Thurm 13:01, 8. Okt 2007 (CEST) Im ALB-Auszug 35 werden die Namensnummern nur bis zur zweiten Stelle angezeigt obwohl sie in der Datenbank komplett gespeichert sind. Beispiel: In der Spalte namensnr der Tabelle alb_g_eigentuemer ist der Wert 2.01.01 gespeichert. Im ALB-Formular 35 steht dann nur 2.01.

+ Nachweise mit alphanumerischer Blattnummer anzeigen

Damit die Nachweise mit alphanumerischer Blattnummer nach einer Recherche korrekt angezeigt werden muß in nachweisanzeige.php die Zeile

<td><div align="center"><?php echo $this->formvars['blattnummer']=str_pad(intval($this->nachweis->Dokumente[$i]['blattnummer']),3,'0',STR_PAD_LEFT); ?></div></td>

durch diese hier ersetzt werden:

<td><div align="center"><?php echo $this->formvars['blattnummer']=str_pad($this->nachweis->Dokumente[$i]['blattnummer'],3,'0',STR_PAD_LEFT); ?></div></td>

+ Zuweisung von Festpunkten zu einem Antrag

--Andreas Thurm 10:17, 19. Sep 2007 (CEST)Seit dem ich in der php.ini die erforderlichen Änderungen betreffs des Übergangs zur Version 1.65 vorgenommen habe, kann ich keine Festpunkte mehr zu einem Antrag zuordnen. Ein Klick auf den dem entsprechenden Button führt zu keinem Ergebnis. Es wird die momentan aktuelle Seite wieder aufgebaut.

+ Erzeugen eines Arbeitsdrucks (index.php?go=ExportMapToPDF)

--Reißland 09:38, 17. Sep 2007 (CEST) Beim erstellen eines "Arbeitsdrucks" (go-Variable=ExportMapToPDF) erhält man nicht wie in vorherigen Versionen die Angaben Gemarkung, Flur, Flurstück sondern lediglich die Ausschrift "Array".

+ Fehler in der Rechteverwaltung

Wer eine MySQL-Version kleiner 4.10 hat, der bekommt beim Setzen der Layerattributrechte einen Fehler. Zum Beheben in der Funktion set_attributes_privileges in users.php in diesem Abschnitt:

if(MYSQLVERSION < 410){
  $sql = 'REPLACE INTO layer_attributes2stelle SET ';
  $sql.= 'layer_id = '.$layer_id.', ';
  $sql.= 'stelle_id = '.$this->id.', ';
  $sql.= 'attributename = "'.$attributename.'", ';
  $sql.= 'privileg = '.$privileg.', ';
  if($tooltip == 'on'){
     $sql.= ', tooltip = 1';
  }
  else{
     $sql.= ', tooltip = 0';
  }
  if($tooltip == 'on'){
     $sql.= 'tooltip = 1';
  }
  else{
     $sql.= 'tooltip = 0';
  }
  ...

diese Zeilen entfernen:

if($tooltip == 'on'){
  $sql.= ', tooltip = 1';
}
else{
  $sql.= ', tooltip = 0';
}

--Hschmidt 10:20, 19. Sep 2007 (CEST)

+ Layerattribut-Rechteverwaltung

Die Layerattribut-Rechteverwaltung ist selbst nicht geschützt und lässt sich in jeder Stelle über index.php?go=Layerattribut-Rechteverwaltung aufrufen. Besser wäre es wenn diese nur über die Adminstratorfunktionen aufzurufen wäre.

- maxsize bei den Attributen im GLE

--Markus Hentschel 12:30, 7. Sep 2007 (CEST)
Bei der Eingabe von Sachdaten im GLE kann man mehr Zeichen eingeben, als laut Definition in der Postgis zugelassen sind. Entsprechend gibts eine Fehlermeldung beim Speichern und das Speichern scheitert. Die Länge der Input-Felder muss auf die Attribut-Zeichenlänge laut DB-Definition begrenzt sein.

+ Verschieben des Bildausschnittes beim Setzen eine Umrings

--Benutzer:Karsten Daedelow 11:55, 7. Sep 2007 -- > Will man beim Setzen eines Umrings den Bildauschnitt schieben, verschwindet der Umring und man kann von vorn beginnen.

--Rahn 14:22, 12. Sep 2007 (CEST) Um den Fehler zu beheben, in der SVG_Utilities.php die Zeile

if(top.document.GUI.newpath.value && polygonfunctions == true){

durch diese hier ersetzen:

if(top.document.GUI.newpath.value){

- Maßstab der Karte nach Absenden von Geometrieänderungen

--Markus Hentschel 15:32, 5. Sep 2007 (CEST)
Ich bin mir nicht sicher, ob es gewollt oder ein Bug ist: Wenn man eine Geometrie bearbeitet hat und beim Bearbeiten in die Karte gezoomt hat, kommt man nach dem Senden wieder in den originalen Maßstab, den man vor dem Bearbeiten hatte. Das macht das Bearbeiten aber sehr mühselig, wenn man an einem Objekt mehrere Änderungen zu machen hat. Besser wäre, generell den jeweils letzten Maßstab zu behalten.

+ Generischer Layereditor | Geometrieabfrage-Layer: Flurstuecke

--Hschmidt 10:17, 5. Sep 2007 (CEST)
Bei der Auswahl des Flurstückslayers als Geometrieabfrage-Layer um z.B. Flurstücksgeometrien hinzuzufügen kommt im Fläche-Fensterchen folgende Fehlermeldung, die evtl. darauf hindeutet, dass keine Geometrie übergeben wird:

Warning:  pg_query() function.pg-query: Query failed: ERROR:  unterminated quoted string at or near "'\'))::numeric, 2)
at character 32 in /usr/local/httpd-2.2.3/htdocs/kvwmap-1.6.6/class/postgresql.php on line 3809 Fehler bei SQL Anweisung: 
SELECT round(Area(GeomFromText('\'))::numeric, 2)

Das gleiche zeigt sich auch in der Log-Datei. Bei anderen PostGis-Layern wie z.B. Fluren funktioniert das Hinzufügen von Geometrien.

--Rahn 09:20, 12. Sep 2007 (CEST) Das hängt damit zusammen, dass für den Flurstückslayer 2 Tabellen abgefragt werden, die beide eine Spalte the_geom haben. Nämlich alkobj_e_fla und alkobj_t_pkt. Für die Geometrieabfrage wird das Attribut verwendet, welches im Data-Statement an erster Stelle steht. Also the_geom. Es ist aber nicht klar, welches the_geom abgefragt werden soll und die Abfrage funktioniert nicht. Damit sie funktioniert, muß man die Unterabfrage so umbenennen wie die Tabelle alkobj_e_fla und diesen Bezeichner dann vor the_geom setzen. Also z.B. so:

o.the_geom from (select o.objnr as oid,o.objart,o.folie,o.the_geom,f.flurstkennz,f.gemkgschl,
t.label from alkobj_e_fla AS o,alknflst as f,alkobj_t_pkt AS t WHERE o.folie='001' AND o.objnr=f.objnr 
AND o.objnr=t.objnr) as o using unique oid using srid=2398

--Hschmidt 09:03, 19. Sep 2007 (CEST)
Prima jetzt klappt es:-) Nützlich wäre noch in den Install und Update-Scripten das Data-Statement des Flurstückslayers daraufhin zu ändern.

+ PostGIS Update per SQL

--Markus Hentschel 15:15, 4. Sep 2007 (CEST)
postgis_update.sql: In den CREATE TABLE Befehlen von den Tabellen anliegerbeitraege_bereiche und anliegerbeitraege_strassen ist jeweis der folgende Constraint zu viel und muss rausgelöscht werden:

CONSTRAINT enforce_dims_the_geom CHECK (ndims(the_geom) = 2)

Dasselbe in der Datei postgis_install.sql

- config.php Kennzeichnung der Änderungen

--Hschmidt 14:25, 4. Sep 2007 (CEST)

Leider sind in der config-default.php nicht alle Änderungen gekennzeichnet. Das macht die Aktualisierung etwas mühselig.
Der Eintrag "$Gazdb->dbName='gazetteers'; # Version 1.6.6" sollte auskommentiert werden, weil er sonst bei fehlender DB zu einer Fehlermeldung führt.

Version 1.6.5

+ Layernamen mit Sonderzeichen in der Drucklegende

--Markus Hentschel 14:17, 15. Aug 2007 (CEST)
Beinhaltet ein Layername Sonderzeichen oder Leerzeichen, die als HTML-Characters geschrieben sind (Beispiel: "Gebäude" o.ä.), dann stehen diese HTML-Characters in der Legende. Sie müssten durch die richtigen Zeichen ersetzt werden.

- Lagebezeichnung im ALB-Ausdruck

--Markus Hentschel 10:58, 15. Aug 2007 (CEST)

Hat die Lagebezeichnung eines Flurstücks im ALB mehrere Hausnummern, weden diese momentan alphanumerisch und nicht numerisch sortiert: aus "1, 2, 3, 10" wird "1, 10, 2, 3". Die Hausnummern sollten aber numerisch sortiert bleiben.
Gibt es sehr viele Hausnummern, wird momentan über den Rand des Dokuments hinaus geschrieben, d.h. man kann den Rest der Hausnummern nicht mehr lesen. Hier müssten Zeilenumbrüche erfolgen, wobei die jeweils nächste Zeile linksbündig dort anfangen müsste, wo in der ersten Zeile der Lagebezeichnung der Straßenname anfängt (nicht der Straßenschlüssel!).

+ Stellenwechsel

--Reißland 10:13, 27. Jul 2007 (CEST)

Beim Wechsel einer Stelle wird der Extent der Karte aus der aktuellen Stelle für die neue Stelle übernommen.
Bei der Auswahl einer Stelle erscheint ein IE-Error AHAH-Error 12029 Unknown. Liegt das an der Version des IE (bei mir 6.0.2900.2180)?

--Rahn 15:39, 27. Jul 2007 (CEST) Guck mal weiter unten beim Bug "Stellenauswahl".

+ Nachweisverwaltung - Nachweise löschen

--HolgerR 16:01, 26. Jul 2007 (CEST)
Im Rechercheergebnis wird auch den berechtigten Stellen das Recht zum Löschen von Nachweisen nicht eingeräumt. Abhilfe schafft hier die Korrektur des Snippets 'nachweisanzeige.php'. Der Eintrag

         	<? if($this->Stelle->isFunctionAllowed('Nachweiseloeschen')){ ?>

in Zeile 127 muss richtig

         	<? if($this->Stelle->isFunctionAllowed('Nachweisloeschen')){ ?>

heißen. Im Funktionsname ist quasi ein 'e' zuviel.

--Rahn 15:36, 27. Jul 2007 (CEST) Tja, das ist jetzt die Frage ob wir alle das Snippet ändern oder den Namen der Funktion in der Datenbank. Ich kann mich erinnern, dass die MST-Leute auch schon auf das Problem gestoßen waren und wir damals den Funktionsnamen in der Datenbank in "Nachweiseloeschen" geändert haben. Deswegen schlag ich vor, dass alle anderen das auch so machen.

- Sachdatenabfrage

--HolgerR 08:35, 26. Jul 2007 (CEST)
Wird aus der Karte heraus eine Sachdatenabfrage mit dem Info-Button durchgeführt, erzeugen PostGIS-Kartenthemen, die keine OID-Spalte besitzen einen Fehlereintrag in der PostgreSQL-Logdatei.

2007-07-25 11:32:01 CEST user datenbank [local] 23211 SELECT ERROR:  column "oid" does not exist
2007-07-25 11:32:01 CEST user datenbank [local] 23211 SELECT STATEMENT:  SELECT oid from alknflst limit 1

Dieser Fehler wird in der Funktion 'check_oid' in postgresql.php durch die fehlende OID-Spalte generiert. Das ist zwar nicht weiter schlimm, für die Übersichtlichkeit der Logdatei ist es aber doch nicht optimal. Abhilfe könnte m.E. folgende geänderte Funktion 'check_oid' schaffen:

 function check_oid($tablename){
   $sql = 'SELECT * FROM '.$tablename.' LIMIT 1';
   @$query=pg_query($sql);
   $anz_felder = pg_num_fields($query); # Anzahl der Felder in jeweiliger Tabelle
   $j = 0;
   $rueckgabe_wert = false;
   while ($j <> $anz_felder AND $rueckgabe_wert = false) {
     $feldname = pg_field_name($query, $j); # Herauslesen der Feldnamen
     if ($feldname == 'oid') {
       $rueckgabe_wert = true;
     } # if
   } # while
   return $rueckgabe_wert;
 } # function check_oid

Vielleicht gibt es elegantere Lösungen. Es wäre jedoch auf alle Fälle gut, wenn wegen der Übersichtlichkeit in der PostgreSQL-Logdatei der Fehlereintrag in Zukunft verhindert wird.

--Rahn 11:03, 26. Jul 2007 (CEST)
Mit SELECT * FROM <Tabelle> fragt man zwar alle Spalten der Tabelle ab, aber nicht die systeminterne Spalte oid, auch wenn sie vorhanden ist.

- menues2stelle bei Änderungen

--Markus Hentschel 07:34, 26. Jul 2007 (CEST)
Wenn man mit dem Stelleneditor Änderungen in einer Stelle vornimmt, werden beim Absenden ALLE Untermenüs eines Obermenüs an die Stelle und an alle User der Stelle gebunden. Das ist u.U. nicht gewollt. Die Jagdbezirkssuche oder die Bauauskunft sind z.B. normalerweise nicht in allen Stellen nötig.
--SigridP 12:51, 26. Jul 2007 (CEST)
Da im Stelleneditor die Menuepunkte nur als Obermenue (z.B. Suchen) zugeordnet werden können, werden bei Änderungen alle Menues mit der Menueebene 2 innerhalb eines Obermenues übernommen. Ich habe mir so geholfen, dass ich einige Menues, wie z.B. Bauauskunft und Jagdkataster ohne Obermenue mit der Menueebene 1 definiert habe.

--Markus Hentschel 08:43, 13. Aug 2007 (CEST)

Ja, an so was habe ich auch schon gedacht. Aber eigentlich ist es ja in Ordnung, wenn es ein Obermenü "Suche" gibt, in der alle Suchfunktionen vereinigt sind. Wenn dann nebenher noch einige Suchfunktionen in Menüebene 1 herumgeistern, ist es doch vielleicht für den Anwender ein bißchen irritierend, weil unlogisch. Eine grundsätzliche Lösung wäre meiner Meinung nach besser.

- Referenzkarte bei maximalem Extent im Druck

--Markus Hentschel 08:22, 25. Jul 2007 (CEST)
Wenn der Zoomfaktor der Referenzkarte im Druckrahmen > 1 ist und man den maximalen Extent (z.B. den ganzen Landkreis) drucken will, dann wird die Referenzkarte entsprechend auf den maximalen Extent gesetzt, sondern hat den halben maximalen Extent der Karte (halb = vermutlich Zoomfaktor?). Den EXTENT im refmapfile.map zu vergrößern, bringt nichts.

+ Trefferliste Namenssuche

--Markus Hentschel 13:05, 11. Jul 2007 (CEST)
Nicht direkt ein Fehler, aber wegen Geringfügigkeit auch kein Entwicklungswunsch: Es wäre besser, wenn in der Trefferliste der Namenssuche die Attribute "Geburtsdatum/Zusatz", "Name/Firma", "Straße HausNr" und "PLZ Ort" eine linksbündige Ausrichtung hätten.

+ logconsume in Stelle anlegen

--Markus Hentschel 10:38, 10. Jul 2007 (CEST)
Beim Anlegen einer Stelle kann ich den logconsume nicht auswählen, entsprechend kommt nach dem Speichern eine Fehlermeldung.

--Rahn 11:06, 13. Jul 2007 (CEST) Die Fehlermeldung kann eigentlich nur kommen, wenn die Spalte logconsume auf NOT NULL gesetzt ist.

--Markus Hentschel 11:59, 17. Jul 2007 (CEST) Die Spalte logconsume ist aber auf NULL gesetzt!?

+ SHP-Import

Beim Shp-Import hat sich noch ein Bug eingeschlichen. Zum Beheben des Fehlers in kvwmap.php in der Funktion shp_import_speichern die Zeile

exec(POSTGRESBINPATH.'psql -f '.IMAGEPATH.$this->formvars['table_name'].'.sql '.$this->pgdatabase->dbName.' '.$this->pgdatabase->dbName);

durch

exec(POSTGRESBINPATH.'psql -f '.IMAGEPATH.$this->formvars['table_name'].'.sql '.$this->pgdatabase->dbName.' '.$this->pgdatabase->user);

ersetzen. Damit die Anzahl der eingelesenen Datensätze auch noch richtig angezeigt wird, die Zeile

showAlert('Import erfolgreich. Die Tabelle '.$this->formvars['table_name'].' wurde erzeugt und '.count.' Datensätze eingelesen.');

durch

showAlert('Import erfolgreich. Die Tabelle '.$this->formvars['table_name'].' wurde erzeugt und '.$count.' Datensätze eingelesen.');

ersetzen.

+ Stellenauswahl

--SigridP 08:48, 12. Jun 2007 (CEST)Nach dem Befehl "Stelle Wählen" und der Auswahl einer neuen Stelle + "WEITER" kommt die Meldung:

Fehler beim Wechseln der Stelle. Prüfen Sie die Angaben.

Dabei wird unter aktuelle Kartenausdehnung: die Eintragung"undefined" durch die Koordinaten ersetzt. Bei erneutem Betätigen von "WEITER" funktioniert der Stellenwechsel.

--Rahn 10:45, 13. Jul 2007 (CEST) Bei einigen lag der Fehler daran, dass 2 Konstanten in der der php.ini falsch gesetzt waren. Beide müssen auf OFF gesetzt sein:

magic_quotes_gpc = Off

magic_quotes_runtime = Off

Version 1.6.4

+ Fehler in Flurstücksabfrage aus der Grafik bei räumlichen Fliter

--HolgerR 09:08, 12. Jun 2007 (CEST) Bei der Flurstueckssuche ueber die Grafik tritt bei Stellen, deren Flurstuecksanzeige durch einen raeumlichen Filter begrenzt ist, ein Fehler auf. In meinem Fall ist als Filterkriterium die 'gemeinde' hinterlegt. In der phplog erfolgt folgender Eintrag:

[08-Jun-2007 12:35:51] PHP Warning:  pg_query(): Query failed: ERROR: column "gemeinde" does not exist in /srv/www/htdocs/kvwmap_svg/class/postgresql.php on line 3640

Haengt das vielleicht mit dem Statment in der Spalte 'pfad' zusammen? Da wird ja das Attribut als 'template erforderlich'::text AS gemeinde hinterlegt. Kann php / PostgeSQL das so nicht auswerten? Ich nutze PostgreSQL in der Version 8.1.3 und php in der Version 4.3.10. Was kann ich tun, um den Fehler zu umgehen?

Hallo Holger,

da hast Du ein Problem entdeckt, was wir beim Erstellen des Pfad-Statements für den Layer Flurstücke nicht bedacht hatten. Alle abgefragten Attribute im Pfad-Statement sind ja praktisch Pseudo-Attribute, das heißt sie kommen nicht aus den Tabellen, sondern haben alle den Wert 'Template erforderlich' und werden nur deshalb im Select aufgeführt, um die Rechte für die einzelnen Attribute setzen zu können. Die eigentlich Abfrage der Sachdaten erfolgt dann im Template über readALBdata().

Macht man eine Abfrage auf den Flurstückslayer, der einen Filter enthält, so funktioniert der Filter natürlich nicht, weil es ja ,wie gesagt keine richtigen Attribute sind. Um wieder nach Attributen filtern zu können, muss man die entsprechenden Attribute korrekt ins Pfad-Statement einbauen. Für das Attribut gemeinde also z.B. so

select alkf.flurstkennz, 'template_erforderlich'::text AS flurnr, 'template_erforderlich'::text AS entsteh, 'template_erforderlich'::text AS letzff, 'template_erforderlich'::text AS flaeche, 'template_erforderlich'::text AS karte, 'template_erforderlich'::text AS kreisid, 'template_erforderlich'::text AS kreisname, 'template_erforderlich'::text AS gemkgschl, 'template_erforderlich'::text AS gemkgname, gemkg.gemeinde AS gemeinde, 'template_erforderlich'::text AS gemeindename,'template_erforderlich'::text AS finanzamt,'template erforderlich'::text AS finanzamtname, 'template_erforderlich'::text AS forstschluessel, 'template_erforderlich'::text AS forstname, 'template_erforderlich'::text AS lagebezeichnung, 'template erforderlich'::text AS nutzung, 'template erforderlich'::text AS ausfstelle,'template erforderlich'::text AS verfahren, 'template erforderlich'::text AS vorgaenger, 'template erforderlich'::text AS bestandsnr,'template erforderlich'::text AS eigentuemer, 'template erforderlich'::text AS freitext, 'template erforderlich'::text AS hinweis,'template erforderlich'::text AS baulasten, 'template erforderlich'::text AS amtsgerichtname, 'template erforderlich'::text AS amtsgerichtnr,'template erforderlich'::text AS grundbuchbezirkname, 'template erforderlich'::text AS grundbuchbezirkschl, 'template erforderlich' AS klassifizierung 
FROM alknflst as alkf, alkobj_e_fla AS alko, alb_v_gemarkungen as gemkg
WHERE alko.folie='001' AND alko.objnr = alkf.objnr AND gemkg.gemkgschl = alkf.gemkgschl

Gruß,

Stefan

In der Spaltendeklaration reicht m.E. weiterhin das 'template erforderlich', Hauptsache in der FROM- und WHERE - Klausel sind die richtigen Eintragungen gemacht.

Holger

+ Flurstückssuche - Anzeige in der Karte - Abbruch in Zeile 8791

--HolgerR 09:00, 1. Jun 2007 (CEST) Wird bei wiederholter Flurstückssuche das herausgefilterte Flurstück über 'Kartenausschnitt' in der Karte präsentiert und das Suchergebnis nicht gelöscht, so erscheint ab der zweiten Präsentation eines Flurstücks oberhalb der Karte die Ausschrift:

Abbruch in Zeile 8791

Der Abbruch erfolgt in kvwmap.php in der Function 'new_Style'.

In der Tabelle 'styles' wird beim erstmaligen Anlegen des temporären Styles für das herausgefilterte und anzuzeigende Flurstück ein Style mit der 'style_id' '0' angelegt. Für die darauffolgenden Suchergebnisse wird wieder versucht ein Style mit der ID '0' anzulegen. Da aber die Spalte 'style_id' als Primärschlüssel definiert ist, kommt es hier zur Kollision. Abhilfe schafft u.a. das Zuweisen von 'AUTO_INCREMENT' auf die Spalte 'Style_ID' mit folgendem Befehl

ALTER TABLE styles CHANGE COLUMN Style_ID INT NOT NULL AUTO_INCREMENT;

Da ja schon Daten in der Tabelle enthalten sind ist es notwendig mit

ALTER TABLE styles AUTO_INCREMENT = wert;

den Autowert auf den höchsten freien Wert einzustellen. Das ist ein datenbankseitiger Lösungsvorschlag. Eventuell kann das ja auch programmseitig abgefangen werden? Stefan, Peter habt ihr da eine Lösung?

--HolgerR 13:01, 5. Jun 2007 (CEST) Beim Erstellen der MySQL-Datenbank mit Hilfe der zur Verfügung gestellten SQL-Skripts tritt dieser Fehler nicht auf, da hier die Spalte 'style_id' auf 'AUTO_INCREMENT' eingestellt wird. Zu diesem Fehler braucht also nichts weiter getan werden.

- Fehlerhafte Angaben bei der Ausgabe des zuständigen Grundbuchamts

--FrankGiese 15:22, 16. Mai 2007 (CEST)

Ich musste feststellen, dass bei unseren ALB-Auszügen teilweise falsche Angaben zum zuständigen Grundbuchamt ausgegeben werden. Mit der ersten Abfrage habe ich bis zu 9 Grundbuchbezirke in einer Gemarkung gefunden. Kvwmap gibt aber nur den ersten gefundenen Datensatz heraus. Wenn er zufällig, wie in meinem Fall ein Grundbuchamt im Nachbarkreis bezeichnet, wird diese Angabe für die gesamte Gemarkung benutzt.

Für Abfrage nach Grundbuchbezirksnummern in einer ausgewählten Gemarkung

SELECT DISTINCT gb.amtsgericht AS schluessel,a.name, gb.grundbuchbezschl, f.gemkgschl FROM alb_g_buchungen AS b,alb_flurstuecke AS f,alb_v_grundbuchbezirke AS gb,alb_v_amtsgerichte AS a WHERE gb.grundbuchbezschl=b.bezirk AND b.flurstkennz=f.flurstkennz AND gb.amtsgericht=a.amtsgericht AND f.gemkgschl=130621

Für Abfrage nach Grundbuchbezirksnummern in einer ausgewählten Gemarkung wenn zusätzlich die Blattnummer ausgegeben werden soll

SELECT DISTINCT gb.amtsgericht AS schluessel,a.name, gb.grundbuchbezschl, f.gemkgschl, b.blatt FROM alb_g_buchungen AS b,alb_flurstuecke AS f,alb_v_grundbuchbezirke AS gb,alb_v_amtsgerichte AS a WHERE gb.grundbuchbezschl=b.bezirk AND b.flurstkennz=f.flurstkennz AND gb.amtsgericht=a.amtsgericht AND f.gemkgschl=130621

+ Infoabfrage auf Punktlayer der PostGIS

--Markus Hentschel 13:14, 16. Mai 2007 (CEST)
Abfragen auf Punktobjekte, die aus der DB stammen, scheitern bei einfachem Klick in die Karte - man muss ein Rechteck aufziehen. Alle Einträge bei "tolerance" werden nicht beachtet.

+ Mehrere Hinweise zu einem Flurstück

--Andreas Thurm 11:13, 2. Mai 2007 (CEST) Wenn zu einem Flurstück in der Tabelle alb_f_hinweise mehrere Hinweise (also auch mehrere Zeilen) vorhanden sind, wird nur der erste Hinweis im ALB-Auszug und in der Sachdatenanzeige berücksichtigt.

+ fehlende Maßstabseingabe

--Markus Hentschel 07:46, 26. Apr 2007 (CEST)
Wenn man die Maßstabsangabe im Feld unter der Karte löscht, aber keinen neuen Wert eingibt, dann gibts bei der nächsten Aktion (zoomen, pannen etc.) nur noch eine Fehlermeldung. Das müßte abgefangen werden.

- PDF-Ausgabe "für alle Flurstücke" bei sehr vielen Flurstücken

--Markus Hentschel 15:35, 17. Apr 2007 (CEST)
Bei einer sehr großen Zahl von Flurstücken in der Sachdatenanzeige Flurstücke funktioniert die PDF-Ausgabe "für alle Flurstücke" nicht mehr, es kommt nach längerer Zeit lediglich eine nichtssagende Fehlermeldung.

+ Adresssuche bei der ersten Straße einer Gemeinde

--Markus Hentschel 15:35, 17. Apr 2007 (CEST)
Bei der Adresssuche kann man (immer noch nicht) nach den Hausnummern der ersten angezeigten Straße suchen.

- Probleme mit Druckrahmen

--Hschmidt 10:26, 17. Apr 2007 (CEST)

Wenn man einer Stelle nur einen Druckrahmen zugeordnet hat, kann man keine Druckvorschau produzieren, weil kein Druckaussschnitt gewählt werden kann.
Beim Druckrahmeneditor (go=Druckrahmen) lässt sich ein Wasserzeichen einfügen, aber nicht nachträglich löschen. Änderungen werden nicht gespeichert. Ebenso scheinen Probleme bei der Änderung von Eintragungen im Feld "ursprünglicher Maßstab" zu bestehen.

- ALB 20 u. 25 | fehlende Ausgabe von Miteigentumsanteil u.a.

--Hschmidt 11:12, 16. Apr 2007 (CEST)
Bei der Ausgabe der ALB-Formate 20 uund 25 fehlen die Angaben zum Miteigentumsanteil, Sondereigentum und Aufteilungsplan-Nr.. Diese Angaben befinden sich in der Tabelle "alb_b_grundstuecke" in den Spalten "anteil", "sondereigentum" und "auftplannr".

+ Klassen ausblenden

--Hschmidt 11:55, 12. Apr 2007 (CEST)
Die Datei gui.php aus dem custom-Ordner dieser Version enthält nicht die neue Funktion "updateclasses" mit dem Klassen der Layer in der Legende ausgeblendet werden können. Als Vorlage für eine custom-GUI sollte man die Datei gui.php aus dem layouts-Ordner verwenden.

+ Druckprobleme

--Hschmidt 14:38, 5. Apr 2007 (CEST), geändert 31.05.07

Beim Druck treten Fehlermeldungen auf bzgl. unzureichender Schreib-Rechte auf das Verzeichnis " PDFClass/fonts ". Abhilfe kann man sich verschaffen indem man die Rechte entprechend hoch setzt (z.B. 777).
Der Adobe Reader meldet nach Erstellung der PDF-Datei in einem Fensterchen "In der Schrift "php_Times-Roman" ist der Wert für /BBox fehlerhaft.". Abhilfe kann man sich verschaffen indem man die entsprende Schrift ohne "php_" verwendet z.B.: Times-Roman statt php_Times-Roman.
Das bei den Anwendern sehr beliebte direkte Drucken in eine PDF-Datei (go=ExportMapToPDF) funktioniert nicht mehr :-(

--Rahn 13:45, 31. Mai 2007 (CEST) Geht in der 1.6.5 wieder

Bei schwacher Netzanbindung kann es zu Problemen kommen die PDF-Dateien im Browser-Plugin zu öffnen. Der Vorgang wird abgebrochen und der Browser meldet "angehalten". Abhilfe bringt die Änderung des Umgangs mit den PDF-Dateien in den Browsereinstellungen. Bei Firefox ab Ver. 2.0 unter "Extras | Einstellungen | Inhalt | Dateitypen verwalten ..." Dort PDF auswählen und "Aktion ändern" in "Dateien auf Diskette/Festplatte speichern". Dann wird die Datei erst heruntergeladen und kann im Download-Fensterchen problemlos geöffnet werden. Irgendwie scheint das aber ein kvwmap-spezifisches Problem zu sein, weil an den entsprechenden Arbeitsplätzen andere PDFs (auch größere) problemlos im Plugin geöffnet werden können!

- Shape-Export

--Markus Hentschel 11:45, 2. Apr 2007 (CEST)

Umlaute in Layernamen bzw. dann im Shapenamen müssten in "Ae", "ae" usw. gewandelt werden, sonst kann der Shape nicht gedownloaded werden und hat auch nicht den richtigen Namen.
Beim Eingrenzen über ein Polygon tauchen im SQL-Statement Backslashes auf, mit denen zumindest meine Postgres-Version 7.4.8 nichts anfangen kann.

--Rahn 14:11, 2. Apr 2007 (CEST) Warum die Backslashes bei einigen auftauchen und bei einigen nicht, ist noch nicht geklärt. Um sie zu entfernen in kvwmap.php in der Funktion shp_export_exportieren nach der Zeile

$sql = $this->formvars['selectstring'];

die Zeile

$sql = str_replace("\\", "", $sql);

einfügen.

--Markus Hentschel 11:45, 16. Mai 2007 (CEST) Wenn ich eine Shapedatei erzeuge, bekomme ich nach dem Alert-Fenster mit der Meldung des erfolgreichen Erzeugens des Shapes eine Fehlermeldung:

Warning: unlink(/srv/www/htdocs/tmp/shp_Export_Fluren509/Fluren.shp) [function.unlink]: No such file /
or directory in /srv/www/htdocs/kvwmap/class/kvwmap.php on line 3265

Der anschließende Klick auf "Herunterladen" funktioniert nicht, weil die zip-Datei im tmp-Verzeichnis nicht existiert.

Version 1.6.3

+ Fachschale Jagdkataster | Tabelle Jagdbezirke

--Hschmidt 11:32, 26. Mär 2007 (CEST)
In der Tabelle jagdbezirke fehlt offensichtlich die Spalte "name". Beim Versuch einen Datensatz abzuspeichern kommt die entspr. Fehlermeldung.

+ Druckrahmen - 'als neuen Rahmen speichern' - Referenzkarte

--HolgerR 16:02, 22. Mär 2007 (CET)

Beim Anlegen von Druckrahmen auf Basis vorhandener Druckrahmen wird bei Nichtvorhandensein einer Referenzkarte der Stringwert 'NULL' in die Tabelle 'druckrahmen' in das Feld 'refmapsrc' eingetragen. Beim Aufruf dieses Rahmens bricht kvwmap mit einem weißen Bildschirm ab.

Eine einfache Lösung besteht darin, in phpMyAdmin das Feld 'refmapsrc' auf NULL zu setzen. Beim Anlegen mehrer Rahmen ist das ganz schön umständlich. Daher habe ich die Funktionen wie folgt angepasst Änderungen

+ ALB-Einleseroutine: Hinweise zum Flurstück

--Andreas Thurm 08:34, 16. Mär 2007 (CET) Mir ist aufgefallen, dass Hinweise zum Flurstück, welche im ALB gelöscht worden sind in kvwmap noch vorhanden sind.

--HolgerR 15:51, 22. Mär 2007 (CET)

Andreas siehe mal meinen Hinweis zur Version 1.6.2: Hinweis

+ Löschen von Freitexten

--Markus Hentschel 11:37, 8. Mär 2007 (CET) Wenn ich in der druckrahmenverwaltung einen Freitext lösche, lande ich anschließend nicht in meiner bearbeiteten Druckvorlage, sondern in der "aktuellen Druckvorlage". Frage: Ist das mit der "aktuellen Druckvorlage" überhaupt nötig?

+ ALB-Formate 20 und 25 ohne Wasserzeichen

--Markus Hentschel 14:07, 2. Mär 2007 (CET) Obwohl ich die Funktion "ohneWasserzeichen" einer Stelle nicht zugeordnet habe, erscheint der Link "ohne WZ" sowohl bei ALB-Auszug 20 als auch bei ALB-Auszug 25 und das PDF wird erzeugt.

+ Suchknopf über Fenster in der Dokumentenrecherche

--M.Leschke 15:55, 19. Feb 2007 (CET) In der Dokumentenrecherche der Nachweisverwaltung wird der Auswahlknopf über Viereck nicht als aktiv (gelb) dargestellt. Außerdem muß er bei der ersten Benutzung mit Doppelklick und später mit einfachem Klick aktiviert werden. Das Gleiche gilt für den Umringspolygon-löschen Knopf in der Nachweisverwaltung.

- ALB-Einleseroutine - Baulasten hist. Flurstuecke

--HolgerR 09:29, 9. Feb 2007 (CET) Die Baulastenblätter von untergegangenen Flurstücken werden weiter in der Datenbank vorgehalten. Ist das so gewollt? m.E. nach wird eine ausgefeilte Flurstückshistorie zum derzeitigen Stand in kvwmap nicht geführt und die Daten sind somit nicht mehr notwendig.

Lt. dem SQL-Dump werden die Angaben zwar zuerst gelöscht, aber anschließend wieder der Tabelle alb_f_baulasten angefügt.

INSERT INTO alb_x_flurstuecke (flurstkennz,gemkgschl,flurnr,pruefzeichen) VALUES ('132311-001-00193/003.00','132311','001','4');
UPDATE alb_x_flurstuecke SET flurstkennz='132311-001-00193/003.00',status='H',entsteh='2005/03019-11',letzff='2006/03544-11',flaeche=144511,aktunr=03 WHERE flurstkennz='132311-001-00193/003.00';
INSERT INTO alb_x_f_baulasten (flurstkennz,blattnr) VALUES ('132311-001-00193/003.00','40002');

DELETE FROM alb_f_baulasten USING alb_x_f_baulasten WHERE alb_f_baulasten.flurstkennz=alb_x_f_baulasten.flurstkennz;
INSERT INTO alb_f_baulasten SELECT * FROM alb_x_f_baulasten;

Die Einleseroutine müsste so weit verbessert werden, das beim 1. INSERT zu alb_x_f_baulasten der Status 'H' des Flurstückes mit ausgewertet wird und diese Baulasten in die temporäre Datei nicht eingetragen wird. Die anderen Einleseroutinen zu den weiteren Flurstückattributen bin ich jetzt nicht durchgegangen, aber ich könnte mir vorstellen, das es hier ähnlich aussieht. z.B. Hinweise zum Flurstück aus dem SQL-Dump:

DELETE FROM alb_f_hinweise USING alb_x_f_hinweise WHERE alb_f_hinweise.flurstkennz=alb_x_f_hinweise.flurstkennz;
INSERT INTO alb_f_hinweise SELECT * FROM alb_x_f_hinweise;

Wenn eine umfassende Flurstückhistorie gewünscht ist, könnten in diesem Fall die Funktionen deleteHistXXX aus dem Programmcode entfernt werden. Die historischen Flurstücke müssten dann aber auch in der Tabelle alb_flurstücke mit dem Status 'H' belegt und nicht gelöscht werden.

+ ALB-Einleseroutine - deleteOldxxx

--HolgerR 14:21, 8. Feb 2007 (CET) beim der Anzeige der Baulasten ins kvwmap ist mir aufgefallen, dass neben den untergegangenen Verfahren und Hinweisen auch die untergegangenen Baulasten nicht richtig gelöscht werden. Ich könnte mir vorstellen, dass die Funktionen

deleteOldAdressen
deleteOldLagen
deleteOldNutzungen
deleteOldKlassifizierungen
deleteOldTexte
deleteOldAnlieger
deleteOldBaulasten

in der postgresql.php vom fehlerhaften Löschansatz betroffen sind.

Das Problem ist, dass in der wldge keine Löschdatensätze enthalten sind. Untergegangene Flurstücke werden historisch gesetzt (Status 'H'). Bei Änderungen zum Flurstück werden nur die Änderungen mitgeteilt. Fällt jetzt ein Datensatz weg, wie z.B. eine eingetragene Baulast zu einem Flurstück, wird diese 'R'-Zeile in der wldge-Datei einfach nicht mehr aufgeführt. Der Abgleich zum Löschen der Baulast kann daher nicht gegen die neu eingelesen alb_x_f_baulast erfolgen - hier steht die untergegangene Baulast nicht mehr drin - , sondern der Abgleich muss im Vergleich zu allen eingelesen Flurstücken alb_x_flurstuecke erfolgen. Hier habe ich mal die korrigierte Fassungen der Funktionen hinterlegt

+ Query im Polygon

--Markus Hentschel 13:24, 2. Feb 2007 (CET) Wenn ich eine Abfrage im Polygon machen will und ich mich "verpolygoniert" habe, habe ich keine Möglichkeit, das Zeichnen des Polygons abzubrechen. Auch der Klick auf einen anderen Button hilft nicht.

--HolgerR 13:04, 5. Feb 2007 (CET)

Markus vorübergehend hilft jede Aktion, die den Karteninhalt neu lädt, also 'Pan', 'Neu laden', Zoom, ...

Du hast aber recht, bei erneutem Anklicken des Polygonabfragebuttons müsste die Möglichkeit bestehen, den Polygon wieder neu zu zeichnen.

--Rahn 12:04, 8. Feb 2007 (CET) Ist behoben. In der nächsten Version kann man durch einen weiteren Klick auf den Button das Polygon löschen.

+ Selektionslayer

--Markus Hentschel 13:24, 2. Feb 2007 (CET) Wenn ein Selektionslayer gelöscht wird, indem der Benutzer den Haken rausnimmt und neu lädt, werden die entsprechenden Einträge in den Tabellen "styles2classes", "used_layer" und "rolle2used_layer" nicht gelöscht. Oder habe ich nur ein Problem mit meiner MySQL?

--Rahn 12:49, 5. Mär 2007 (CET) Die Selektionslayer werden jetzt in der Tabelle rollenlayer gespeichert.

+ Fehlermeldung im generischen Layereditor

Beim Aufruf des generischen Layereditors kann es (je nach Postgres-Version) vorkommen, dass Fehlermeldungen angezeigt werden. Zur Behebung des Problems in postgresql.php in der Funktion pg_table_constraints() die Zeile

$sql = "SELECT consrc FROM pg_constraint WHERE contype = 'check'";

durch diese hier ersetzen:

$sql = "SELECT consrc FROM pg_constraint, pg_class WHERE contype = 'check'";

+ punktförmige Bodenrichtwertzonen kopieren

--Certa 12:34, 25. Jan 2007 (CET) Der Versuch, punktförmige Bodenrichtwerte in einen neuen Stichtag zu kopieren, scheitert, weil die Funktion versucht, in die Spalte "textposition" der Tabelle "bw_bodenrichtwertzonen" zu schreiben. die existiert aber nicht bei punktförmigen Bodenrichtwerten. Außerdem steht in allen Masken "Bodenrichtwertzonen", obwohl ich es nicht mit Zonen, sondern mit Punkten zu tun habe.

--Rahn 13:30, 25. Jan 2007 (CET) Um den Fehler beim Kopieren zu beheben, in bodenrichtwerte.php in der Funktion copyZonenToNewStichtag() die Zeile

$sql.=",sanierungsgebiete,sichtbarkeit,'".$newStichtag."',the_geom,textposition";

durch diese Zeilen ersetzen:

if(BODENRICHTWERTTYP == 'punkt'){
   $sql.=",sanierungsgebiete,sichtbarkeit,'".$newStichtag."',the_geom";
}
else{
   $sql.=",sanierungsgebiete,sichtbarkeit,'".$newStichtag."',the_geom,textposition";
}

+ Fachschale Jagdkataster

Damit auch Sonderflächen erfasst werden können, muss dass entsprechende constraint der Tabelle jagdbezirke wie folgt geändert werden:

ALTER TABLE jagdbezirke DROP CONSTRAINT art;
ALTER TABLE jagdbezirke ADD CONSTRAINT art CHECK (art::text = 'gjb'::text OR art::text = 'ejb'::text OR art::text = 'tjb'::text OR art::text = 'sf'::text);

+ Geometrien erfassen

Damit in den verschiedenen Fachschalen auch Multipolygone gespeichert werden können, muss das entsprechende constraint der Tabelle wie folgt geändert werden:

ALTER TABLE <TABELLENNAME> DROP CONSTRAINT enforce_geotype_umring;
ALTER TABLE <TABELLENNAME> ADD CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) = 'POLYGON'::text OR geometrytype(the_geom) = 'MULTIPOLYGON'::text OR the_geom IS NULL);

== - Nachweisverwaltung - Dokument überarbeiten - doppelte Dokumentnamenvergabe == --HolgerR 17:20, 16. Jan 2007 (CET) Wird bei der Änderung von Dokumenten der Dokumentenname eines schon vorhandenen Dokumentes generiert (z.B. Vergabe einer schon vorhanden laufenden Nummer im Dokumentenstamm) erscheint eine leere Fehlermeldung. Bitte mit Inhalt füllen, damit der Nutzer weiß, was er verkehrt gemacht hat.

+ Attribut-Editor verweigert Änderungen

--Markus Hentschel 12:28, 16. Jan 2007 (CET) Ich kann im Attribut-Editor nicht die Formularelement-Einstellungen der Attribute ändern. Ich kriege folgende Fehlermeldung:

Warning: mysql_error(): supplied argument is not a valid MySQL-Link resource
in /srv/www/htdocs/kvwmap/class/mysql.php on line 2339

== + PDF-Druckfunktion - fehlende Schrift == --HolgerR 13:42, 15. Jan 2007 (CET) In der PDF-Druckfunktion erhalte ich bei der Übergabe des Bildes an den Acrobat Reader folgende Fehlerausschrift:

Eine Schrift ist nicht im Ressourcen-Dictionary verzeichnet - Helvetica wird verwendet.

In der phplog-Datei wird folgender Eintrag generiert:

[15-Jan-2007 13:15:39] PHP Warning:  Unable to set output format to 'jpeg_print' in /srv/www/htdocs/kvwmap_dev/class/kvwmap.php on line 2196

Welche Schrift fehlt hier und wo muss die stehen? Ist da serverseitig oder clientseitig was zu tun? Ist vielleicht PHP nicht richtig compiliert?

--Rahn 23:27, 15. Jan 2007 (CET) Diese Fehlermeldung bedeutet nur, dass eine Schriftart, die für den Druckrahmen ausgewählt wurde, nicht vom Acrobat Reader unterstützt wird (Zur Auswahl stehen ja alle Fonts der PDF-Class). Um die Fehlermeldung zu vermeiden, einfach eine andere auswählen, z.B. Helvetica.

Der Eintrag in der Log-Datei hat nichts mit der falschen Schriftart zu tun. Hier wurde nur protokolliert, dass für den Druck versucht wurde ein Output-Format zu setzen (jpeg_print), dass offenbar nicht definiert ist. Die Output-Formate stehen in der defaultmapfile.map. Das Format jpeg_print wurde in der Version 1.5.8 eingeführt, um eine höhere Druckqualität zu erzielen (die jpg-Qualität ist hier 100%). Beim PDF-Export wird versucht, dieses Format zu setzen. Wenn dies fehlschlägt, wird das Standardformat jpeg verwendet. Es ist also nichts wirklich schlimmes, allerdings empfiehlt es sich für den Druck doch jpeg_print als Outputfprmat zu verwenden.

+ Layer werden nicht mehr angezeigt

Im Stelleneditor und nach "Layer anzeigen" kann es sein, dass die Layer nicht angezeigt werden. Dazu in der users.php in der Funktion getLayers() die Zeile

$sql .=' AND layer.Gruppe = u_groups.id AND NOT u_groups.Gruppenname = "Suchergebnis"';

durch diese ersetzen:

$sql .=' AND layer.Gruppe = u_groups.id AND u_groups.Gruppenname != "Suchergebnis"';

und in kvwmap.php in der Funktion getall_Layer() in die Zeile

$sql.=' WHERE layer.Gruppe = u_groups.id AND NOT u_groups.Gruppenname = "Suchergebnis"';

durch diese hier:

$sql.=' WHERE layer.Gruppe = u_groups.id AND u_groups.Gruppenname != "Suchergebnis"';

+ Fehler in der Flurstückssuche

--Rahn 10:17, 10. Jan 2007 (CET) Wer den Internetexplorer benutzt, dürfte beim Aufruf der Flurstückssuche bemerkt haben, dass hier nichts angezeigt wird. Zur Behebung des Bugs einfach die erste Zeile in flurstueckssuche.php:

<script language="JavaScript" src="funktionen/selectformfunctions.js" type="text/javascript">

umd das fehlende End-Tag erweitern:

</script>

Version 1.6.2

+ Darstellung Label - partials

--HolgerR 10:11, 19. Dez 2006 (CET) Die Änderung der Einstellung zu der partiellen Darstellung der Label in der Tabelle 'labels', Spalte 'partials' ist ohne Wirkung. In der Mapdatei wird immer der Standardwert 'TRUE' verwandt.

Lösung: In der Datei 'kvwmap.php' in der Funktion 'loadclasses' unterhalb von

        $klasse->label->set('force',$dbLabel['the_force']);

folgende Zeile einfügen

        $klasse->label->set('partials',$dbLabel['partials']);

- Stellenabhängige Maßstabseinstellungen in 'used_layer'

--HolgerR 11:28, 15. Dez 2006 (CET) In der Tabelle 'used_layer' sind zur stellenabhängigen Maßstabseinstellungen die Spalten 'minscale' und 'maxscale' hinterlegt. In der Mapdatei werden leider nur die Eintragungen aus der Tabelle 'layer' verwandt.

+ zurück zur Flurstückssuche

--Markus Hentschel 13:10, 6. Dez 2006 (CET) Nach einer Flurstückssuche sollte man aus der Sachdatenanzeige heraus wieder zurück in die Flurstückssuche gehen können, wobei das zuletzt gesuchte Flurstück vorselektiert ist. Bei mir klappt das nicht. Die entsprechende FST-Nummer wird mit go=Flurstueck_Auswählen nicht übergeben.

+ Fehler beim Überarbeiten von Dokumenten in der Nachweisverwaltung

--M.Leschke 13.50, 16. Nov 2006 (CEST) Beim Überarbeiten von Dokumenten in der Nachweisverwaltung wird das Umringspolygon für den zu bearbeitenden Nachweis zwar geladen (es wird blau markiert), nach Änderung des Datensatzes (Datum oder Stammnummer)erschient aber folgende Fehlermeldung:

Bitte legen Sie das Umringspolygon für den einzuarbeitenden Nachweis fest.

--Rahn 12:56, 8. Dez 2006 (CET): Zur Behebung des Fehlers in der Funktion changeDokument in nachweis.php die Zeile

$ret=$this->pruefeEingabedaten($formvars['datum'],$formvars['VermStelle'],$formvars['art'],$formvars['gueltigkeit'],$formvars['stammnr'],$formvars['Blattformat'],$formvars['Blattnr'],$formvars['changeDocument'],$formvars['Bilddatei_name'],$formvars['pathlength'],$formvars['pathx'],$formvars['pathy']);

durch diese hier erseten:

$ret=$this->pruefeEingabedaten($formvars['datum'],$formvars['VermStelle'],$formvars['art'],$formvars['gueltigkeit'],$formvars['stammnr'],$formvars['Blattformat'],$formvars['Blattnr'],$formvars['changeDocument'],$formvars['Bilddatei_name'],$formvars['pathlength'],$formvars['umring']);

+- Mapserverfehler nach Betätigung Druckvorschaubutton

Nach bisher nicht erkennbaren Muster sendet der Mapserver nach Betätigung des Druckvorschaubuttons gelegentlich folgende Meldung:

Fatal error: [MapServer Error]: msDrawLegend(): Unable to initialize image in /Pfad zu kvwmap/class/kvwmap.php on line 1082

--Rahn 13:07, 30. Okt 2006 (CET) Ist uns auch schon aufgefallen. Warum das so zufällig auftritt, wissen wir auch noch nicht. Auf jeden Fall verursacht die Legendenerzeugung diese Fehlermeldung. Läßt man die Legende weg (Legendenbreite rausnehmen), wird man von den Fehlermeldungen verschont.

+ Druckrahmen Änderungen speichern

Versucht man im Druckrahmeneditor die vorgenommenen Änderungen an einem Druckrahmen zu speichern oder einen neuen anzulegen, kommt eine Fehlermeldung und es erfolgt keine Speicherung. Zur Behebung die Zeile

$sql .= ", `font_text` = '".$formvars['font_text']."'";

in den Funktionen update_frame und save_frame in kvwmap.php löschen.

+ Nordpfeil

--Markus Hentschel 11:54, 20. Okt 2006 (CEST) Die rechte Hälfte der Pfeilspitze sollte weiß und nicht transparent sein.

+ Drehwinkel

--Markus Hentschel 14:18, 18. Okt 2006 (CEST) Beim Eingeben eines Drehwinkels funktioniert die Druckvorschau nicht, es kommt folgende Meldung: "Fatal error: Call to undefined function: imagerotate() in /srv/www/htdocs/kvwmap/class/kvwmap.php on line 1002"

--Rahn 12:05, 19. Okt 2006 (CEST) Entweder Dein GD ist nicht richtig installiert, was ich aber nicht glaube oder Deine php-Version ist zu alt. Laut Dokumentation wird PHP > 4.3.0 benötigt.

--Markus Hentschel 14:59, 19. Okt 2006 (CEST) PHP 4.3.8 ist installiert. Wie erkenne ich denn, ob meine GD nicht richtig installiert ist?

--Rahn 10:19, 24. Okt 2006 (CEST) Ich denke mal es liegt hier dran: In der Dokumentation zur dieser Funktion auf www.php.net steht: Anmerkung: Diese Funktion steht nur zur Verfügung, wenn PHP mit der GD Bibliothek übersetzt wurde, die mit PHP zusammen erhältlich ist.

+ Suchergebnislayer

--Markus Hentschel 13:59, 18. Okt 2006 (CEST) Die Layer mit Suchergebnissen dürfen nicht bei "Layer anzeigen" und "Stelle anzeigen" auftauchen.

--SigridP 10:25, 3. Nov 2006 (CET) Die Layer sollten ohne Kästchen für eine Sachdatenabfrage sein, da bei Aktivschalten unnötige Fehlermeldungen erzeugt werden.

+ PDF-Dokmente laden

--Markus Hentschel 13:55, 18. Okt 2006 (CEST) Mitarbeiter, die einen Umlaut im Namen haben, können PDF-Dokumente (z.B. ALB- oder Druck-Dokumente) nicht laden. Sie erhalten ein "Objekt nicht gefunden". Vorschlag: Alle Sonderzeichen aus dem Dokumentnamen entfernen (Leerzeichen und Doppelpunkte) und die Umlaute im Benutzernamen ersetzen lassen.

--Rahn 11:48, 19. Okt 2006 (CEST) Zur Behebung in kvwmap.php in der Funktion output() die Zeile

$dateiname = $this->user->Name.'-'.$currenttime.'.pdf';

durch folgende Zeilen ersetzen:

$name = str_replace('ä', 'ae', $this->user->Name);
$name = str_replace('ü', 'ue', $name);
$name = str_replace('ö', 'oe', $name);
$name = str_replace('Ä', 'Ae', $name);
$name = str_replace('Ü', 'Ue', $name);
$name = str_replace('Ö', 'Oe', $name);
$name = str_replace('ß', 'ss', $name);
$dateiname = $name.'-'.$currenttime.'.pdf';

+ ALB-Anzeige für alle Flurstücke

--Markus Hentschel 13:38, 18. Okt 2006 (CEST) Die Flurstücksangaben fehlen in den PDF-Dokumenten aller Formate bei "Für alle Flurstücke".

+ Fehler in der Flächenversiegelung

Um ihn zu beheben in kvwmap.php in der Funktion versiegelungsFlaechenErfassung die Zeile

$GemObj=new gemeinde(0,$this->database);

durch diese ersetzen:

$GemObj=new gemeinde(0,$this->pgdatabase);

+- Geometrieeditor: Polygon zeichnen

--Markus Hentschel 12:48, 18. Okt 2006 (CEST) Wenn ich ein Polygon zeichnen oder ein Flurstück hinzufügen will, bekomme ich im IE ein Alert: "AHAH-Error: 401 Authorization required".

--HolgerR 10:50, 24. Nov 2006 (CET)

Bei mir tritt der gleiche Fehler auf. In der apache-Fehlerdatei wird folgender Eintrag erzeugt:

[Fri Nov 24 12:05:30 2006] [error] [client 10.32.62.45] File does not exist: /srv/www/htdocs/kvwmap_dev/10.32.0.246, ref
erer: http://10.32.0.246/kvwmap_dev/index.php

Hallo, ich habe da einen Fehler im Quellcode gefunden: In class/spatial_processor.php in class spatial_processor in Funktion spatial_processor Befinden sich zwei syntaktisch falsche Zeilen:

 $this->$conn_id = $this->database->open();
 $this->$pgconn_id = $this->pgdatabase->open();

Diese müssen heißen:

 $this->conn_id = $this->database->open();
 $this->pgconn_id = $this->pgdatabase->open();

Vielleicht leigt es ja daran, dass einige PHP-Processoren das akzeptieren, anderen nicht. In Ndbg hat das zumindest weitergeholfen.

Peter

+ ALB-Daten werden nicht angezeigt

Bei den ALB-Auszügen fehlen sämtliche Daten zum Flurstück. Um dies zu beheben, in alb.php in der Funktion ALBAuszug_Flurstueck die Zeile

$ret=$flst->readALB_Data($FlurstKennz);

durch diese ersetzen:

$ret=$flst->readALB_Data($FlurstKennz[$f]);

+ History-Buttons

--Markus Hentschel 13:08, 17. Okt 2006 (CEST) Die beiden History-Buttons funktionieren nicht mehr.

--Rahn 13:53, 19. Okt 2006 (CEST) Zur Behebung in users.php in der Funktion setConsumeActivity die Zeile

if ($prev=="0000-00-00 00:00:00" OR $prev=='') {

durch diese ersetzen:

if ($prevtime=="0000-00-00 00:00:00" OR $prevtime=='') {

+ ALB-Auszüge für alle aufgelisteten Flurstücke

Das Wasserzeichen erscheint nur auf der ersten Seite, aber nicht mehr auf allen folgenden.

--Rahn 11:56, 18. Okt 2006 (CEST) Zur Behebung in alb.php in der Funktion ALBAuszug_Flurstueck die Zeilen

if ($wasserzeichen) {
   $pdf->addJpegFromFile(WWWROOT.APPLVERSION.WASSERZEICHEN,75,140,450); # 2005-12-15 pk
}

ausschneiden und hinter die Zeile

for($f = 0; $f < count($FlurstKennz); $f++){

einfügen.

+ Polygon löschen bei der Dokumenteneingabe

Im Geometrieeditor der Dokumenteneingabe hat sich ein kleiner Fehler eingeschlichen. Will man ein gezeichnetes Polygon wieder löschen, so funktioniert dies nicht und es kommt (im IE) eine Fehlermeldung. Zur Behebung des Problems in SVG_Polygon.php folgende Zeile unter "formular-variabeln fuer fachschale" einfügen:

<input name="area" type="hidden" value="">

+ Geometrieeditor Bodenrichtwertzonen erfassen

Hier gibt es genau denselben Fehler. Hier zur Fehlerbehebung die Datei SVG_polygon_and_point.php um die Zeile

<input name="area" type="hidden" value="">

erweitern.

+ Löschen eines Suchergebnisses

Zur Zeit kann man die Suchergebnislayer nur in der Layerverwaltung löschen. Ersetzt man die Funktion setAktivLAyer in users.php durch folgenden Code, wird der Suchergebnislayer durch Wegnehmen des Hakens und anschließendes neu laden gelöscht.

function setAktivLayer($formvars, $stelle_id, $user_id) {
   # Eintragen des Status der Layer, 1 angezeigt oder 0 nicht.
   for ($i=0;$i<count($this->layerset);$i++) {
     if ($formvars['thema'.$this->layerset[$i]['Layer_ID']]==1) {
       $aktiv_status=1;
     }
     elseif($formvars['thema'.$this->layerset[$i]['Layer_ID']]==2) {
       $aktiv_status=2;
     }
     else{
       $aktiv_status=0;
     }
     $sql ='UPDATE u_rolle2used_layer SET aktivStatus="'.$aktiv_status.'"';
     $sql.=' WHERE user_id='.$this->user_id.' AND stelle_id='.$this->stelle_id;
     $sql.=' AND layer_id='.$this->layerset[$i]['Layer_ID'];
     $this->debug->write("file:users.php class:rolle->setAktivLayer - Speichern der aktiven Layer zur Rolle:",4);
     $this->database->execSQL($sql,4, $this->loglevel);
     // -------------- new
     if($aktiv_status == 0){
        $mapdb = new db_mapObj($stelle_id, $user_id);   
           $Gruppe = $mapdb->read_Group($this->layerset[$i]['Gruppe']);
           if($Gruppe['Gruppenname'] == 'Suchergebnis'){
              $mapdb->deleteLayer($this->layerset[$i]['Layer_ID']);
              # auch die Klassen löschen
              $classes = $mapdb->read_Classes($this->layerset[$i]['Layer_ID']);
              for($j = 0; $j < count($classes); $j++){
                 $mapdb->delete_Class($classes[$j]['Class_ID']);
              }
              $layer[] = $this->layerset[$i]['Layer_ID'];
              $stelle[] = $stelle_id;
              $Stelle = new Stelle($stelle_id, $this->database);        # <----- Zeile war fehlerhaft
              $Stelle->deleteLayer($layer);
              $this->deleteLayer($user_id, $stelle, $layer);
           }
      }
     // --------------- new
   }
   return 1;
 }

--SigridP 11:54, 13. Okt 2006 (CEST) Bei mir kommt dann folgende Fehlermeldung:

Warning: Missing argument 2 for setaktivlayer() in /srv/www/htdocs/kvwmap-1.6.2/class/users.php on line 905

Warning: Missing argument 3 for setaktivlayer() in /srv/www/htdocs/kvwmap-1.6.2/class/users.php on line 905

--Rahn 13:19, 13. Okt 2006 (CEST) Stimmt, man muss natürlich auch noch den Aufruf der Funktion in kvwmap.php

$this->user->rolle->setAktivLayer($this->formvars);

so anpassen:

$this->user->rolle->setAktivLayer($this->formvars,$this->Stelle->id,$this->user->id);

--Markus Hentschel 12:41, 17. Okt 2006 (CEST) Besser wäre vielleicht, wenn das Suchergebnis in die PostGIS und nicht in die MySQL geschrieben wird. Es ist unheimlich schwierig, neue Layer mit Classes etc. anzulegen, wenn alle naselang neue Layer von kvwmap angelegt werden und die nächsthöhere ID beanspruchen. Und zur Anzeige am Bildschirm: Bei mir wird jetzt in der Themenauswahl als Suchergebnis nicht die komplette Flurstücksnummer, sondern nur Gemarkung-Flur ausgegeben. Außerdem steht da immer "Flurstücke:", wäre Singular nicht sinnvoller?

+ Leere letzte Seite bei den ALB-Auszügen

Bei allen Flurstücks-ALB-Auszügen wird noch eine leere letzte Seite hinten angehängt. Wen 's stört kann in alb.php !! am Ende !! der Funktion ALBAuszug_Flurstueck() die Zeile

$pageid=$pdf->newPage();

durch folgende Zeilen ersetzen.

if($f < count($FlurstKennz)-1){
   $pageid=$pdf->newPage();
}

== - ALB Fortfuehrungsart 57 - Loeschen der alten Eintraege für Hinweise und Verfahren == --HolgerR 15:21, 12. Okt 2006 (CEST)

Bei der Fortfuehrungsart 57 werden bei mehreren Flurstuecken folgende Angaben uebereinstimmend veraendert:

Kennung - Bezeichnung

D - Flurkarte, Riss; Baublock; Finanzamtszugehoerigkeit; Fortsamtszugehoerigkeit

U - Ausfuehrende Stelle / Verfahren

F - Hinweise zum Flurstueck.

Diese Angaben koennen eingetragen, geaendert oder geloescht werden. Bei Eintragungen und Aenderungen laeuft alles wie es soll, da die ensprechenden Kennungen in der WLDGe enthalten sind und die Einleseroutine darauf reagieren kann.

Fallen diese Angaben zu den Flurstuecken weg, wird in der WLDGe kein Loeschsatz erzeugt, sondern die Angaben werden einfach nicht mit aufgefuehrt. Darauf reagiert der WLDGE2SQL-Konverter bislang noch nicht, auch nicht in vorhergehenden Versionen. Dadurch existieren in der ALB-Anwendung z.B. Flurstuecke mit Verfahrenseintraegen, die so nicht mehr gueltig sind.

Daraus ergeben sich m.E. folgende Konsequenzen:

Die alten Eintragungen in den Tabellen `alb_f_hinweise` und `alb_f_verfahren` sind in Uebereinstimmung mit den Flurstueckskennzeichen aus der WLDGe, die in der temporaeren Tabelle `alb_x_flurstuecke` enthalten sind, zu loeschen. Dies betrifft die Funktionen `deleteOldVerfahren()` und `deleteOldHinweise()` in `postgresql.php`.

Die korrigierte Funktion `deleteOldVerfahren()` sieht wie folgt aus:

 function deleteOldVerfahren() {
   $sql ="DELETE FROM alb_f_verfahren";
   #Eingefügt 11.04.2006 H. Riedel
   if(POSTGRESVERSION == '8.1'){
     $sql.=" USING alb_".$this->tableprefix."flurstuecke";
   }
   $sql.=" WHERE alb_f_verfahren.flurstkennz=alb_".$this->tableprefix."flurstuecke.flurstkennz";
   return $this->execSQL($sql, 4, 0);
 }

und die Funktion `deleteOldHinweise()` wie folgt:

 function deleteOldHinweise() {
   $sql ="DELETE FROM alb_f_hinweise";
   #Eingefügt 11.04.2006 H. Riedel
   if(POSTGRESVERSION == '8.1'){
     $sql.=" USING alb_".$this->tableprefix."flurstuecke";
   }
   $sql.=" WHERE alb_f_hinweise.flurstkennz=alb_".$this->tableprefix."flurstuecke.flurstkennz";
   return $this->execSQL($sql, 4, 0);
 }

Um die Werte in der Datenbank zu aktualisieren sind abschließend die ganzen BZSN, angefangen bei der Grundausstattung, neu einzulesen.

Version 1.6.1

+ Anzeige und Drucken von ALB-Auszug 20 und ALB-Auszug 25 falsch

--Rahn 10:07, 2. Okt 2006 (CEST) Beim ALB-Auszug 20 und 25, dann darf der Eigentümer nur einmal erscheinen. Zur Zeit ist es so, dass der Eigentümer für jedes Flurstück, dass im Grundbuchblatt geführt ist, erneut aufgeführt wird.

--Rahn 11:00, 2. Okt 2006 (CEST) Diesen und noch ein paar andere Fehler bei den ALB-Auszügen 20 und 25 behoben.

+ Eigentümernachweis im ALB-Auszug

--SigridP 12:39, 20. Sep 2006 (CEST)
Der im Original-ALB-Auszug zu den Privatpersonen angegebene Zusatz "GbR ......" 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.

--Rahn 11:08, 2. Okt 2006 (CEST) In welchen ALB-Formaten ist denn dieser Zusatz erforderlich?

--SigridP 09:36, 5. Okt 2006 (CEST)In allen ALB-Ausdrucken, in denen die Eigentümer aufgeführt werden.

+ Fehler und Abweichungen beim ALB-Druck

--Heinz Schmidt 13:29, 14. Sep 2006 (CEST)
was fehlt:
"Gesetzliche Klassifizierung" (wird, wenn vorh. im orig. ALB unter "Tatsächliche Nutzung" ausgegeben)

debug: --Pkorduan 16:15, 14. Sep 2006 (CEST) Ok, das fehlt wirklich. Hier ist kein Fehler oder fehlende Daten im ALB, sondern tatsächlich im Quellcode. Zum Debuggen bitte folgende Änderung in postgresql.php in der Funktion getKlassifizierung($FlurstKennz) vornehmen:

an Stelle von:

return $Klassifizierung;

folgendes eintragen:

$ret[1]=$Klassifizierung;
return $ret;

Wer noch möchte, dass das Wort "Summe" groß ausgegeben wird in der ALB-Anzeige, muss die Zeile in alb.php in Funktion ALBAuszug_Flurstueck($FlurstKennz,$formnummer,$wasserzeichen) so aussehen:

$pdf->addText($col0,$row-=12,$fontSize,'Summe');

"Ausführende Stelle" (wird, wenn vorh. im orig. ALB unter "Hinweise" ausgegeben)

debug: --Pkorduan 15:06, 14. Sep 2006 (CEST) debug: Ein Statement der Art

SELECT st.ausfstelle AS ausfstelleid,st.name AS ausfstellename,v.flurstkennz,
v.verfnr,v.verfbem AS verfbemid,b.bezeichnung AS verfbemerkung 
FROM alb_f_verfahren AS v,alb_v_ausfuehrendestellen AS st,alb_v_bemerkgzumverfahren AS b 
WHERE v.ausfstelle=st.ausfstelle AND v.verfbem=b.verfbem
AND v.flurstkennz='132295-001- 00003/008.00'

sollte zu einer Ausgabe der ausführenden Stelle führen, aber nur, wenn da auch ein Verfahren läuft auf dem Flurstück und wenn eine Bemerkung zum Verfahren gespeichert ist. Da dies offensichtlich nicht immer der Fall ist, z.B. in LWL, dann muss das Statement anders lauten und zwar so, dass die Ausführende Stelle auch angezeigt wird, obwohl nicht gespeichert ist was ausgeführt wird (das sollte nähmlich in verfbem stehen) Ändern Sie also das SQL-Statement in der Datei postgresql.php in der Funktion function getVerfahren($FlurstKennz) Die Zeilen mit $sql folgendermaßen:

$sql ="SELECT st.ausfstelle AS ausfstelleid,st.name AS ausfstellename";
$sql.=",v.flurstkennz,v.verfnr,v.verfbem AS verfbemid,b.bezeichnung AS verfbemerkung";
$sql.=" FROM alb_f_verfahren AS v LEFT JOIN alb_v_bemerkgzumverfahren AS b ON v.verfbem=b.verfbem";
$sql.=",alb_v_ausfuehrendestellen AS st WHERE v.ausfstelle=st.ausfstelle";
$sql.=" AND v.flurstkennz='".$FlurstKennz."'";

Darin ist der LEFT JOIN zwischen alb_v_bemerkgzumverfahren und alb_f_verfahren enthalten.

--Heinz Schmidt 12:43, 18. Sep 2006 (CEST)
Was jetzt noch fehlt zur "Ausführenden Stelle":
Wenn mehrere "Ausführenden Stellen" eingetragen sind, kommt momentan nur eine.

Ok, das ist jetzt behoben durch zwei Änderungen. Die erste Änderung in postgresql.php in Funktion getVerfahren($FlurstKennz) die Zeile:

$ret[1]=pg_fetch_array($queryret[1]);

ersetzen durch die Zeilen:

while($rs=pg_fetch_array($queryret[1])) {
  $Verfahren[]=$rs;
}
$ret[1]=$Verfahren;

und in alb.php in der Funktion ALBAuszug_Flurstueck(...) die Zeilen für die Darstellung der Verfahren an der Stelle # Verfahren ersetzen. Alter Abschnitt:

# Verfahren
if ($flst->Verfahren['flurstkennz']!=) {
  $pdf->addText($col0,$row-=24,$fontSize,'Ausführende Stelle');
  $pdf->addText($col2_1,$row,$fontSize,$flst->Verfahren['ausfstelleid']);
  $AusfStelleName=zeilenumbruch($flst->Verfahren['ausfstellename'],40);
  $pdf->addText($col4,$row,$fontSize,$AusfStelleName[0]);
  for ($j=1;$j<count($AusfStelleName);$j++) {
    $pdf->addText($col4,$row-=12,$fontSize,$AusfStelleName[$j]);
  }     
  $pdf->addText($col0,$row-=12,$fontSize,'Verfahren');
  $pdf->addText($col2_1,$row,$fontSize,$flst->Verfahren['verfnr']);      
  $pdf->addText($col4,$row,$fontSize,'('.$flst->Verfahren['verfbemid'].')');
  $AusfBemerkung=zeilenumbruch($flst->Verfahren['verfbemerkung'],40);      
  $pdf->addText($col5,$row,$fontSize,$AusfBemerkung[0]);
  for ($j=1;$j<count($AusfBemerkung);$j++) {
    $pdf->addText($col5,$row-=12,$fontSize,$AusfBemerkung[$j]);
  }
}

Neuer Abschnitt:

# Verfahren
$anzVerfahren=count($flst->Verfahren);
for ($i=0;$i<$anzVerfahren;$i++) {
  $pdf->addText($col0,$row-=24,$fontSize,'Ausführende Stelle');
  $pdf->addText($col2_1,$row,$fontSize,$flst->Verfahren[$i]['ausfstelleid']);
  $AusfStelleName=zeilenumbruch($flst->Verfahren[$i]['ausfstellename'],40);
  $pdf->addText($col4,$row,$fontSize,$AusfStelleName[0]);
  for ($j=1;$j<count($AusfStelleName);$j++) {
    $pdf->addText($col4,$row-=12,$fontSize,$AusfStelleName[$j]);
  }     
  $pdf->addText($col0,$row-=12,$fontSize,'Verfahren');
  $pdf->addText($col2_1,$row,$fontSize,$flst->Verfahren[$i]['verfnr']);      
  $pdf->addText($col4,$row,$fontSize,'('.$flst->Verfahren[$i]['verfbemid'].')');
  $AusfBemerkung=zeilenumbruch($flst->Verfahren[$i]['verfbemerkung'],40);      
  $pdf->addText($col5,$row,$fontSize,$AusfBemerkung[0]);
  for ($j=1;$j<count($AusfBemerkung);$j++) {
    $pdf->addText($col5,$row-=12,$fontSize,$AusfBemerkung[$j]);
  }
}

Hinweis:
wenn in der config.php die Konstanten:
'POSTANSCHRIFT', 'POSTANSCHRIFT_STRASSE', 'POSTANSCHRIFT_PLZ', 'POSTANSCHRIFT_ORT'
mit Werten belegt sind, wird im Ausdruck die Adresse zweimal untereinander ausgegeben. Soll das so sein?

Für Anwender mit ALB-Daten mehrer Kreise in einer Datenbank wäre es sinnvoll, wenn die Katasteramtsziffer (katasteramt) und die Bezeichnung der Behörde mit Anschrift und Tel.Nr. (name) oben rechts auf dem Ausdruck nicht aus der config.php geholt werden würde sondern aus der tabelle "alb_v_katasteraemter" der Datenbank.

Zusätzlich sollte im Ausdruck der Stand der ALB-Daten angegeben werden, da es sich um Sekundärdaten handelt. Dieses Datum sollte aus der Tabelle alb_fortführung das letzte Datum der Spalte "ffzeitraum_bis" sein.

+ Fehler in der Kartendarstellung

--Markus Hentschel 12:48, 12. Sep 2006 (CEST) Wenn zwei User zum selben Zeitpunkt eine Karte erzeugen, erhält der eine das Kartenbild des anderen, obwohl vom Mapserver im tmp-Verzeichnis korrekt zwei Karten abgelegt werden.

--Rahn 12:58, 12. Sep 2006 (CEST) Stimmt, das liegt daran, dass die svg-Datei immer gleich heißt und beide User dann auf dieselbe Datei zugreifen. Um den Fehler zu beheben einfach in der SVG_map.php folgende Zeile:

$svgfile  = 'SVG_map.svg';

durch diese beiden hier ersetzen:

$randomnumber = rand(0, 1000000);
$svgfile  = $randomnumber.'SVG_map.svg';

+ Notizenverwaltung

--Markus Hentschel 15:25, 5. Sep 2006 (CEST) Ich habe erstmalig Notizenkategorien in der Notizenverwaltung angelegt. Sie werden auch in der Auswahlliste angezeigt. Beim Auswählen und (automatischen) Neuladen der Seite sind sie dann jedoch nicht ausgewählt?!

--Pkorduan 15:11, 14. Sep 2006 (CEST) Da hilft erstmal eine Notizkategorie per Hand der Stelle zuzuweisen wenigstens mit Leserechten. Im Formular müssen wir mal schauen, wie wir das anpassen.

+ Nachweisverwaltung: Problem beim Downloaden von TIFF's

--Andreas Thurm 07:50, 12. Sep 2006 (CEST)Ab der Version 1.6.1 gibt es ein Problem beim Anzeigen und Downloaden von Nachweisen im TIFF-Format. Die Dokumente lassen sich nicht anzeigen. Es erscheint die Fehlermeldung, dass hier ein unbekanntes Dateiformat vorliegt. Kopiert man die Datei mit winscp auf den Client,lässt sie sich problemlos anzeigen. In der Version 1.6.0 funktioniert der Download und die Anzeige noch reibungslos. Andere Dateiformate wie z. Bsp. PDF sind von diesem Problem scheinbar nicht betroffen.

--Pkorduan 14:07, 14. Sep 2006 (CEST) Das Problem kann folgendermaßen gelößt werden:

In der Datei kvwmap.php in der Funktion: nachweisDokumentAnzeigen() vor die Zeile:
header("Content-type: image/".$dateinamensteil[1]);

die Zeile

ob_end_clean();

einfügen. Dadurch wird der vorher ausgegebene Header gelöscht und der richtige gesendet.

+ Druckmaßstab

--Markus Hentschel 09:54, 11. Sep 2006 (CEST) Die Orthophotos werden bis zu genau 1:5.000 angezeigt (d.h. Eintrag in der Tabelle used_layer = 1:5.001). Wenn ich mit dem Kartenmaßstab in die Druckausschnittswahl gehe, werden die Orthofotos noch angezeigt. Wenn ich dann weiter in die Druckvorschau gehe, werden sie nicht mehr angezeigt - auch nicht im PDF-Dokument. Wenn ich als Druckmaßstab 1:4.999 wähle, werden sie sowohl in der Druckvorschau als auch im PDF angezeigt. Sie müssen jedoch auch bei 1:5.000 im Druck erscheinen.

--Rahn 10:15, 11. Sep 2006 (CEST) Damit ein Layer bei uns bis 1:5000 angezeigt wird, muss ich bei max_scale 5000 eintragen und nicht 5001. Und bei einem Druckmaßstab von 1:5000 erscheint dieser Layer dann auch in der Druckvorschau und im PDF. Hmmm, wie ist das zu erklären?

+ Sachdatenabfrage

--Pkorduan 11:03, 19. Sep 2006 (CEST) Ein weiteres Problem war, dass die OGR Layer nicht abfragbar waren.

Dazu wurde jetzt in der Datei kvwmap.php in der Funktion SachdatenAnzeige($rect) folgendes hinzugefügt. Hinter den Zeilen:

# Abfrage von Shapelayern
$layer=ms_newLayerObj($map);
$layer->set('data', $layerset[$i]['Data']);

folgene zusätzliche einfügen:

$layer->set('connectiontype',$layerset[$i]['connectiontype']);
$layer->set('connection', $layerset[$i]['connection']);
$layer->set('type',$layerset[$i]['Datentyp']);

--Pkorduan 14:01, 4. Sep 2006 (CEST) Die Sachdatenanfrage liefert einen Fehler, wenn die SRID der Rolle ein andere ist als die des Layers. Eine Sachdatenabfrage auf einer Tabelle mit Fachdaten in der Postgis-DB mit der Version 1.6.1 erzeugt folgende Fehlermeldung:

Warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error at or near ")" at character 244 in /usr/local/httpd-2.2.3/htdocs/kvwmap-1.6.1/class/postgresql.php on line 3332

Es liegt an einem Fehler im Quellcode. In der Funktion SachdatenAnzeige() in der Datei kvwmap.php ist in der Zeile

$sql_where =" AND the_geom &&
Transform(GeomFromText('".$searchbox_wkt."',".$client_epsg."),".$layer_epsg."))";

hinten ein ")" zuviel.

-+ WLDGE2SQL Fehler

--Pkorduan 14:05, 4. Sep 2006 (CEST) Beim Einlesen der WLDGE-Dateien fehlen die Buchungsarten. Der Fehler tritt schon seit 1.6.0 auf, ist aber jetzt erst bemerkt worden.

Grund: Bei der Umstellung des SQL-Statement zur Berücksichtung von mehrfachen Buchungen wurde die Buchungsart versehentlich vergessen. Zur Behebung des Problems folgenden Bugfix durchführen.

Bugfix 2006-09-06 pk: Datei: postgresql.php Funktion: insertGrundstueck

Zeile:

    $sql.="SELECT '".$Bezirk."','".$Blatt."','".$BVNR."'";

ersetzen durch:

    $sql.="SELECT '".$Bezirk."','".$Blatt."','".$BVNR."','".$Buchungsart."'";

+ Suche nach Grundbuchblattnummern

--Andreas Thurm 15:53, 7. Sep 2006 (CEST) Innerhalb der Namensuche ist es jetzt möglich nach Grundbuchblattnummern zu suchen. Diese Suche bringt bei mir als Ergebnis immer die Meldung, dass keine Namen gefunden werden konnten, egal ob die Grundbuchblätter existieren oder nicht.

--Markus Hentschel 08:29, 12. Sep 2006 (CEST) Diese Meldung bekomme ich dann, wenn ich die Grundbuchblattnummer nicht mit führenden Nullen angebe, also z.B. "1234" statt "01234". Das ist unschön, denn wer will schon immer diese ganzen Nullen vorneweg schreiben? Das könnte irgendwie abgefangen werden. Leider helfen hier auch keine Platzhalter, "%1234" funktioniert nicht.

--Pkorduan 15:20, 14. Sep 2006 (CEST) Markus, das kann so nicht ganz stimmen. Wenn Du keine Führenden Nullen eingibst, müsste eigentlich gesagt werden, dass man einen Fehler gemacht hat und 5-stellige Nummern eingeben soll. Exakt: "Angaben fehlerhaft: Die Blattnummer ist keine 5 Zeichen lang."

Also Andreas noch mal genau beschreiben was Du eingibst, mit oder ohne Nullen. Ohne Nullen und Fehler: "Es konnten keine Flurstücke zu dem Grundbuchblatt gefunden werden" kann nur kommen wenn Blattnummer auch wirklich 5 stellig sind, ansonsten sind die Blätter nicht da. Da müssen wir uns noch mal die SQL-Statements ansehen, die abgesetzt werden und in Postgres Client testen. Unabhängig davon könnte ich auch Suche ohne führende Nullen einrichten. Dann bitte auf die ToDo. Dürfte recht schnell gehn.

--Markus Hentschel 10:14, 15. Sep 2006 (CEST) Wenn ich nach Bezirk "132427" und Blatt "00008" suche, kriege ich 1 Treffer. Wenn ich nach Bezirk "132427" und Blatt "8" suche, kriege ich die Meldung "Es konnten keine Namen gefunden werden, bitte ändern Sie die Anfrage!" Ich setzt die Suche ohne führende Nullen auf die ToDo, wenn niemand was dagegen hat.

Version 1.6.0

Anzeige der Zeichenreihenfolge

--Markus Hentschel 13:55, 1. Sep 2006 (CEST) Die Anzeige der Zeichenreihenfolge der Layer in der Stellenanzeige zeigt nur 4 Stellen an. Nötig wäre die Anzeige von mindestens 6 Stellen, besser 7.

Festpunkte in KVZ schreiben

--HolgerR 17:11, 7. Aug 2006 (CEST)

Beim Erstellen des KVZ wird bei den Punkten, die eine Höhenangabe besitzen ein Leerzeichen zwischen Hochwert und Höhe zuviel ausgegeben. Kurzfristige Hilfe schafft das Editieren der Datei katasetr.php Zeile 128 wie folgt:

 $zeile.=sprintf("%08.3f",$p["hoe"]); # 48-55 Höhe

statt

 $zeile.=" ".sprintf("%08.3f",$p["hoe"]); # 48-55 Höhe

Namenssuche

--SigridP 09:29, 28. Jul 2006 (CEST)

Bei Eingabe eines Namens kommt die Fehlermeldung:
Es konnten keine Namen gefunden werden, bitte ändern Sie die Anfrage!
Warning: Missing argument 10 for getnamen() in /srv/www/htdocs/kvwmap-1.6.0/class/postgresql.php on line 1713

Druckrahmenverwaltung

--Markus Hentschel 12:03, 18. Jul 2006 (CEST) Der Freitext wird nicht dahin geschrieben, wo er in der Druckrahmenverwaltung (und auch noch in der Vorschau) positioniert wird, sondern zu weit unten und zu weit rechts.

Filterverwaltung

--Rahn 13:31, 27. Jul 2006 (CEST)

Bei Benutzung der Filterverwaltung kann es auch zu einem Fehler kommen, wenn die MySQL-DB älter als Version 4.1.0 ist. Dann lassen sich nämlich keine erstellten Filter abspeichern. Deswegen also am besten eine neuere Version verwenden.

--Rahn 14:33, 18. Jul 2006 (CEST)

Wählt man in der Filterverwaltung einen Layer aus, kann es sein, dass die Attribute nicht geladen werden können und es zu einer Fehlermeldung kommt. Um den Fehler zu beheben, muss man die Funktion getDataAttributes in kvwmap.php durch diese hier ersetzen:

function getDataAttributes($database, $layer_id){
  $sql ='SELECT Data FROM layer WHERE Layer_ID = '.$layer_id;
  $this->debug->write("file:kvwmap class:db_mapObj->getDataAttributes - Lesen der Attribute aus Data:".$sql,4);
  $query=mysql_query($sql);
  if ($query==0) { $this->debug->write("Abbruch Zeile: ".__LINE__,4); return 0; }
  $rs = mysql_fetch_array($query);
  $data = $rs[0];

  if($data != ""){
   	if(strpos($data, '(') === false){
   		$from = stristr($data, 'from');
   		$fooposition = strpos($from, 'as foo');
   		if($fooposition > 0){
   			$from = substr($from, 0, $fooposition);
   		}
   		$select = 'select * '.$from;
   	}
   	else{
             $select = stristr($data,'(');
             $select = trim($select, '(');
             $select = substr($select, 0, strrpos($select, ')'));
   	}
     $attribute = $database->getFieldsfromSelect($select);
     return $attribute;
   }
  else{
    echo 'Das Data-Feld des Layers mit der Layer-ID '.$layer_id.' ist leer.';
    return NULL;
  }
}

config.php

Ist zwar kein richtiger Bug, da wir aber gesagt haben alle Neuerungen in der config.php mit der Versionsnummer zu kennzeichnen, hier der Hinweis:

Es gibt zwei Zeilen, bei denen vergessen wurde, diese zu kennzeichnen:

include (CLASSPATH.'spatial_processor.php');

define("WFS_SRS","EPSG:25833");

Sachdatenanzeige Flurstücke

--Markus Hentschel 13:45, 14. Jul 2006 (CEST) In der flurstuecke.php und der flurstuecksanzeige.php ist das ALB-Format 40 (Eigentümeranzeige) nicht an Rechte gebunden. Es müsste aber genauso laufen wie beim Format 35, dass nämlich das Recht zur Ansicht abgefragt wird.

Adresssuche

--Markus Hentschel 13:42, 14. Jul 2006 (CEST) Nach der Auswahl der Gemeinde werden die Straßen ausgewählt. Die erste Straße der Liste steht bereits im Fenster. Allerdings kann man zu dieser ersten Straße keine Hausnummer auswählen. Man muss zuerst eine andere Straße aufrufen und dann anschließend nochmal die erste Straße.
--Heinz Schmidt 15:22, 17. Jul 2006 (CEST)
Ist bei mir in der Version 1.5.9 auch schon so, war mir aber noch nicht aufgefallen.

Informationsabfrage

--Heinz Schmidt 07:16, 12. Jul 2006 (CEST)

Fehlermeldung "Keine Bearbeitung moeglich! ..."

Nach Aufziehen eines Rechtecks erscheint ein blaues Popup-Fenster mit der Meldung:
"Keine bearbeitung möglich! Uebergebene Daten: ppquery_box, ###,###"
Hingegen arbeitet die punktuelle Informationsabfrage ohne Probleme.

Problemlösung von Stefan Rahn:

um den Fehler zu beheben, in der Datei SVG_map.php die Funktion sendpath durch folgenden Code ersetzen:

function sendpath(cmd,pathx,pathy)   {
   path  = "";
   switch(cmd)
   {
    case "zoomin_point":
     path = pathx[0]+","+pathy[0];
     document.GUI.INPUT_COORD.value  = path;
     document.GUI.CMD.value          = "zoomin";
     document.GUI.submit();
    break;
    case "zoomout":
     path = pathx[0]+","+pathy[0];
     document.GUI.INPUT_COORD.value  = path;
     document.GUI.CMD.value          = cmd;
     document.GUI.submit();
    break;
    case "zoomin_box":
     path = pathx[0]+","+pathy[0]+";"+pathx[2]+","+pathy[2];
     document.GUI.INPUT_COORD.value  = path;
     document.GUI.CMD.value          = "zoomin";
     document.GUI.submit();
    break;
    case "recentre":
     path = pathx[0]+","+pathy[0];
     document.GUI.INPUT_COORD.value  = path;
     document.GUI.CMD.value          = cmd;
     document.GUI.submit();
    break;
    case "pquery_point":
     path = pathx[0]+","+pathy[0]+";"+pathx[0]+","+pathy[0];
     document.GUI.INPUT_COORD.value  = path;
     document.GUI.CMD.value          = "pquery";
     document.GUI.submit();
    break;
    case "pquery_box":
     path = pathx[0]+","+pathy[0]+";"+pathx[2]+","+pathy[2];
     document.GUI.INPUT_COORD.value  = path;
     document.GUI.CMD.value          = "pquery";
     document.GUI.submit();
    break;
    case "ppquery_point":
     top.document.GUI.searchradius.value = "";
     path = pathx[0]+","+pathy[0]+";"+pathx[0]+","+pathy[0];
     document.GUI.INPUT_COORD.value  = path;
     document.GUI.CMD.value          = "ppquery";
     document.GUI.submit();
    break;
    case "ppquery_box":
     top.document.GUI.searchradius.value = "";
     path = pathx[0]+","+pathy[0]+";"+pathx[2]+","+pathy[2];
     document.GUI.INPUT_COORD.value  = path;
     document.GUI.CMD.value          = "ppquery";
     document.GUI.submit();
    break;
    case "pquery_polygon":
     path = pathx[0]+","+pathy[0]+";"+pathx[2]+","+pathy[2];
     document.GUI.INPUT_COORD.value  = path;
     document.GUI.CMD.value          = "pquery";
     document.GUI.submit();
    break;
    default:
     path = pathx[0]+","+pathy[0];
     alert("Keine Bearbeitung moeglich! \nUebergebene Daten: "+cmd+", "+path);
    break;
   }
 }

Stelleneditor - Stelle ändern

--HolgerR 13:48, 21. Aug 2006 (CEST)

Beim Auswählen einer Stelle und 'Als neue Stelle eintragen' sind die Eintragungen zum Layer verschwunden. In der Debug-Datei erscheint folgender Eintrag :

file:users.php class:stelle->copyLayerfromStelle - kopieren der Layer von einer Stelle:
INSERT IGNORE INTO used_layer ( `Stelle_ID` , `Layer_ID` , `queryable` , `drawingorder` , `minscale` , `maxscale` ,
 `offsite` , `Filter` , `template` , `header` , `footer` , `symbolscale`, `logconsume`, `requires` ) 
SELECT 62, `Layer_ID` , `queryable` , `drawingorder` , `minscale` , `maxscale` , `offsite` , `Filter` , `template` ,
 `header` , `footer` , `symbolscale`, `logconsume`, `requires` 
FROM used_layer WHERE Stelle_ID = 8 AND Layer_ID = 1 

Abbruch in Zeile: 1860

Bei mir in der Datenbank fehlt die Spalte 'offsite'. In der 'mysql_update.sql' ist dieser Eintrag zur Tabelle 'used_layer' nicht zu finden.

Die Spalte 'offsite' kann mit folgender SQL-Anweisung eingefügt werden:

ALTER TABLE used_layer
ADD offsite varchar(11) default NULL;

Was wird mit der Spalte 'offsite' bei der Darstellung der Layer bewirkt?

Bei der weiteren Betrachtung des Quellcodes ist mir aufgefallen, dass in den Funktionen 'addLayer' und 'updateLayer' die Anweisungen zur Übernahme/Aktualisierung der Daten aus der Spalte 'requires' fehlen.

Stelleneditor - Menuezuordnung

--HolgerR 14:22, 21. Aug 2006 (CEST)

Ich habe den Effekt, dass bei jedem Ändern der Stelle, sich die Anzahl der Menueeinträge um die ursprüngliche Anzahl der zugeordneten Menues erhöht.

Gibt es eine schnelle Abhilfe?

Version 1.5.9

ALB-Druck 30

fehlende Angaben

--Heinz Schmidt 12:09, 20. Jun 2006 (CEST)
Gesetzliche Klassifizierung
Ausführende Stelle

werden nicht mit ausgegeben!

Katasteramtsziffer

ist nicht variabel, diese sollte aus der DB alb_v_katasteraemter kommen.
Das ist wichtig, wenn man mehrere KVAs in der DB hat wir hier in LWL. Die Ziffer kommt jetzt aus der config.php

--Rahn 13:14, 21. Jun 2006 (CEST)

Wenn man mehrere KVAs in der DB hat, reicht dann die Katasteramtsziffer wirklich aus oder müssten dann nicht auch die Adressen und die Namen der verschiedenen Ämter aus der Datenbank geholt werden und in den Kopf der ALB-Auszüge geschrieben werden?

--Heinz Schmidt 11:25, 14. Sep 2006 (CEST) Ja so sollte es sein. Bei zwei Kreisen in einer DB wie hier LWL und SN sollte beim Ausdruck von Schwerin ALB die schweriner Ziffer erscheinen und die Adresse. Ich stelle die Abweichungen vom original ALB oben unter Vers. 1.6.1 dar.

Kreisziffer

wird im "offiziellen" ALB nicht mit ausgegeben und kann wegfallen. Es sollte im PDF nach "Kreis/Stadt" keine Ziffer ausgegeben werden.

PDF-Export mit Druckrahmen

minscale und maxscale-Problem

Wie schon von einigen fleißigen Anwendern bemerkt, gibt es beim PDF-Export mit Druckrahmen ein Problem mit den minscale- und maxscale-Einstellungen der Layer. Um die hohe Druckqualität zu errreichen, wird die Auflösung des Bildes welches vom Mapserver gerendert wird, um einen gewissen Faktor (hier ist 4 voreingestellt) vergrößert. Wichtig dabei ist jedoch, dass bei allen maßstababhängigen Parametern dieser Faktor mit berücksichtigt wird. Die Parameter minscale und maxscale wurden hier offenbar vergessen. Um den Fehler zu beheben, muss in der Funktion loadmap() in kvwmap.php die Stelle an der minscale und maxscale gesetzt werden

         if ($layerset[$i]['minscale']>0) {
           $layer->set('minscale', $layerset[$i]['minscale']);
         }
         if ($layerset[$i]['maxscale']>0) {
           $layer->set('maxscale', $layerset[$i]['maxscale']);
         }

durch folgenden Code ersetzt werden:

         if ($layerset[$i]['minscale']>0) {
               if($this->map_factor != ""){
           	     $layer->set('minscale', $layerset[$i]['minscale']/$this->map_factor);
         	}
         	else{
         	     $layer->set('minscale', $layerset[$i]['minscale']);
         	}
         }
         if ($layerset[$i]['maxscale']>0) {
         	if($this->map_factor != ""){
           	     $layer->set('maxscale', $layerset[$i]['maxscale']/$this->map_factor);
         	}
         	else{
         	     $layer->set('maxscale', $layerset[$i]['maxscale']);
         	}
         }

Allgemeine Funktionen

Sachdatenabfrage

--Reißland 07:16, 16. Jun 2006 (CEST) Schaltet man die Sachdatenabfrage zu einem Layer nicht aus und verlässt den Min-/MaxScalebereich des Layers so fragt kvwmap bei der Abfrage eines neuen Layers den nicht sichtbaren trotzdem ab.

--Rahn 10:27, 16. Jun 2006 (CEST)

In Version 1.6 behoben.

Anzeige des Logins

--Markus Hentschel 13:57, 8. Jun 2006 (CEST) Unten rechts wird das Login des jeweiligen Users angezeigt. Wäre der Benutzername aus der Tabelle "user" nicht besser?

Falsches Bild bei gleichzeitigem Kartenaufruf

--Markus Hentschel 13:57, 8. Jun 2006 (CEST) Manchmal wird bei einem Benutzer ein ganz anderer Kartenausschnitt angezeigt als der, den er eigentlich erwartet. Beobachtet wurde das bisher nach der Flurstückssuche und anschließendem Klick auf [Kartenausschnitt]. Das scheint immer dann der Fall zu sein, wenn zwei Nutzer (auch in unterschiedlichen Stellen) zeitgleich, d.h. innerhalb derselben Sekunde diesen Klick durchführen.

Speicherung des Kartenausschnitts

--Markus Hentschel 08:37, 25. Apr 2006 (CEST) Wenn eine Sachdatenabfrage durchgeführt wird oder eine andere Funktion, die das Kartenbild verlässt (z.B. eine Namenssuche oder die Auswahl der Kartenfenstergröße etc.), dann wird das als neuer Kartenausschnitt gespeichert. Beim Klick auf "History back" wird einem also ein und derselbe Ausschnitt mehrfach hintereinander präsentiert. Könnte man das abfangen, indem man nur die Kartenausschnitte speichert, deren Koordinaten sich gegenüber dem vorherigen geändert haben?

Fehlermeldung beim Start

--Markus Hentschel 16:41, 5. Apr 2006 (CEST) Beim Start der Version 1.5.9 kommt folgende Fehlermeldung:

Warning: mysql_error(): supplied argument is not a valid MySQL-Link resource
in /opt/lampp/htdocs/kvwmap-1.5.9/class/mysql.php on line 2304

--Rahn 18:20, 5. Apr 2006 (CEST)

In der Datei update_mysql.sql der Version 1.5.9 wurden offenbar zwei SQL-Statements vergessen. Es müssen in die Tabelle u_consume zwei Spalten eingefügt werden und eine Tabelle u_consume2comments muss erstellt werden. Dazu folgende SQL-Statements in MySQL ausführen:

CREATE TABLE `u_consume2comments` (
 `user_id` int(11) NOT NULL,
 `stelle_id` int(11) NOT NULL,
 `time_id` datetime NOT NULL,
 `comment` text collate latin1_german2_ci,
 PRIMARY KEY  (`user_id`,`stelle_id`,`time_id`)
);

ALTER TABLE `u_consume`
ADD `prev` datetime default NULL,
ADD `next` datetime default NULL;

Stellenverwaltung

Zeichenreihenfolge der Layer einer Stelle ändern

--Rahn 10:09, 27. Apr 2006 (CEST)

Im Formular, in der man die Zeichenreihenfolge der Layer einer Stelle editieren kann, gibt es einen Bug. Klickt man auf dieser Seite auf "speichern", so wird die Zeichenreihenfolge aller Layer zwar in die Datenbank übernommen, alle anderen stellenbezogenen Eigenschaften werden jedoch gelöscht!!! Bitte diese Funktion nicht benutzen!!!

--Rahn 09:37, 9. Mai 2006 (CEST)

Um das Problem im Formular, in der man die Zeichenreihenfolge der layer ändern kann, zu beheben, müssen Sie die Funktion 'Layer2Stelle_ReihenfolgeSpeichern' in kvwmap.php durch folgenden Code ersetzen:

function Layer2Stelle_ReihenfolgeSpeichern(){
   $Stelle = new stelle($this->formvars['selected_stelle_id'],$this->user->database);
   $this->titel='Layer der Stelle '.$Stelle->Bezeichnung;
   $this->main='layer2stelle_order.php';
   $this->layers = $Stelle->getLayers(NULL);
   for($i = 0; $i < count($this->layers['ID']); $i++){
     $this->formvars['selected_layer_id'] = $this->layers['ID'][$i];
     $this->formvars['drawingorder'] = $this->formvars['drawingorder_layer'.$this->layers['ID'][$i]];
     $Stelle->updateLayerdrawingorder($this->formvars);
   }
   $this->layers = $Stelle->getLayers(NULL);
   $this->output();
 }

Außerdem muß die Funktion 'updateLayer' in users.php durch die beiden folgenden Funktionen ersetzt werden:

 function updateLayer($formvars){
   # Aktualisieren der LayerzuStelle-Eigenschaften 
   $sql = 'UPDATE used_layer SET Layer_ID = '.$formvars['selected_layer_id'];
   $sql .= ', queryable = "'.$formvars['queryable'].'"';
   $sql .= ', minscale = '.$formvars['minscale'];
   $sql .= ', maxscale = '.$formvars['maxscale'];
   $sql .= ', offsite = "'.$formvars['offsite'].'"';
   $sql .= ', Filter = "'.$formvars['Filter'].'"';
   $sql .= ', template = "'.$formvars['template'].'"';
   $sql .= ', header = "'.$formvars['header'].'"';
   $sql .= ', footer = "'.$formvars['footer'].'"';
   $sql .= ' WHERE Stelle_ID = '.$formvars['selected_stelle_id'].' AND Layer_ID = '.$formvars['selected_layer_id'];
   $this->debug->write("file:users.php class:stelle->updateLayer - Aktualisieren der LayerzuStelle-Eigenschaften:".$sql,4);
   $query=mysql_query($sql,$this->database->dbConn);
   if ($query==0) { $this->debug->write("Abbruch in ".$PHP_SELF." Zeile: ".__LINE__,4); return 0; }
 }

 function updateLayerdrawingorder($formvars){
   # Aktualisieren der LayerzuStelle-Eigenschaften
   $sql = 'UPDATE used_layer SET Layer_ID = '.$formvars['selected_layer_id'];
   $sql .= ', drawingorder = '.$formvars['drawingorder'];
   $sql .= ' WHERE Stelle_ID = '.$formvars['selected_stelle_id'].' AND Layer_ID = '.$formvars['selected_layer_id'];
   $this->debug->write("file:users.php class:stelle->updateLayerdrawingorder - Aktualisieren der LayerzuStelle-Eigenschaften:".$sql,4);
   $query=mysql_query($sql,$this->database->dbConn);
   if ($query==0) { $this->debug->write("Abbruch in ".$PHP_SELF." Zeile: ".__LINE__,4); return 0; }
 }

Nutzerverwaltung

Nutzer anzeigen - ändern - Benutzerdaten Editor

--Markus Hentschel 13:12, 7. Apr 2006 (CEST)Das Wegnehmen von Stellen funktioniert nicht. Nach dem Klick auf "Ändern" wird die ursprüngliche Auswahl wieder angezeigt.

PHP

Fehler in Gebaeude.php

--Heinz Schmidt 09:29, 25. Apr 2006 (CEST)
Ein kleiner aber ärgerlicher Fehler schleppt sich über die Versionen: Die Zeile 33 in der Gebaeude.php lautet:

?><?php

und verursacht eine Fehlermeldung bei der Abrage und sollte so aussehen:

?>

MySQL-Tabellen

Tabelle "used_layer"

--Markus Hentschel 11:26, 8. Mai 2006 (CEST) Ich bin mir nicht sicher, ob es nicht vielleicht am MapServer selber liegt, aber wenn ich im Feld "requires" eine Bedingung eingebe (z.B. für den Layer "Gebäudepunkte" die Bedingung "([Gebäude] = 1)"), dann wird in der Themenauswahl der entsprechende Layer nicht mehr angezeigt, sondern nur noch seine Classes. D.h. er ist nicht mehr separat sichtbar bzw. nicht sichtbar und auch nicht mehr abfragbar bzw. nicht abfragbar zu schalten.

--Rahn 12:45, 12. Mai 2006 (CEST)

Dies ist kein Bug, sondern so gewollt. Schau mal die Dokumentation unter "Tabelle used_layer"

Version 1.5.8

ALB-Anzeige

Eigentümeranzeige

--Markus Hentschel 08:52, 24. Mär 2006 (CET) Im ALB-Auszug wird der Eigentümer manchmal falsch ausgegeben. In der PostGIS ist die Kette korrekt:

alb_flurstuecke.flurstkennz = alb_g_buchungen.flurstkennz
alb_g_buchungen.bezirk = alb_g_eigentuemer.bezirk AND alb_g_buchungen.blatt = alb_g_eigentuemer.blatt
alb_g_eigentuemer.lfd_nr_name = alb_g_namen.lfd_nr_name

Ich komme in der PostGIS immer auf den richtigen Eigentümer. In der PDF-Ausgabe der Buchdaten steht in einigen Fällen gar kein Eigentümer (dann werden auch alle anderen Datenfelder nicht gefüllt) oder der falsche Eigentümer. Ich kann leider nicht erkennen, bei welchen Fällen das so ist und warum.

--Rahn 10:53, 24. Mär 2006 (CET)

Dieser Bug kommt daher, dass fälschlicherweise auf die MySQL-Datenbank und nicht auf die Postgres-Datenbank zugegriffen wird. Um diesen Bug zu beheben, muss in der Datei kvwmap.php in der Funktion ALB_Anzeigen die Zeile

$ALB=new ALB($this->database);

auf

$ALB=new ALB($this->pgdatabase);

geändert werden.

letzte FF in der PDF-Ausgabe

--Markus Hentschel 13:13, 4. Apr 2006 (CEST) Der Eintrag "letzte Fortführung" aus der Tabelle alb_flurstuecke.letzff wird im PDF-Dokument nicht ausgegeben.

Datei:albff org.png

letzte FF im "originalen" ALB

Datei:albff kvwmap.png

letzte FF im "kvwmap" ALB

--Rahn 15:13, 4. Apr 2006 (CEST)

In Version 1.6 behoben

Anteil in der PDF-Ausgabe

--Markus Hentschel 13:13, 4. Apr 2006 (CEST) Das Anteilsverhältnis aus der Tabelle alb_g_eigentuemer.anteilsverhaeltnis wird im PDF-Dokument nicht ausgegeben. Vor das Anteilsverhältnis selbst muss "zu" geschrieben werden.

--Rahn 15:13, 4. Apr 2006 (CEST)

In Version 1.5.9 behoben

Geburtsdatum Eigentümer in der PDF-Ausgabe

--Markus Hentschel 13:13, 4. Apr 2006 (CEST) Wenn in alb_g_namen.name1 kein Zusatz steht (geb. sowieso), muss das Geburtsdatum aus alb_g_namen.name2 trotzdem rechts stehen bleiben und darf nicht nach links unter den Namen rutschen.

Datei:albeig org.png

Anteilsverh. und Geb.-datum im "originalen" ALB

Datei:albeig kvwmap.png

Anteilsverh. und Geb.-datum im "kvwmap" ALB

--Rahn 15:48, 4. Apr 2006 (CEST)

Die Felder name1, name2, name3 und name4 der Tabelle alb_g_namen stehen für die 4 Zeilen, die der Namensblock umfassen kann. Diese Zeilen werden bei entsprechender Füllung der Felder einfach untereinander ausgegeben. Um einen Einfluss darauf zu haben, ob die Informationen (wie z.B. das Geburtsdatum) weiter links oder weiter rechts stehen, muss das entsprechende Feld mit Leerzeichen aufgefüllt werden.

kvwmap-Hilfe

--Heinz Schmidt 14:48, 30. Mär 2006 (CEST)
Die kvwmap-Hilfe, die im Menü angeboten wird, Datei kvwmap-hilfe.html, ist in der Version nicht vorhanden.

Version 1.5.7

Allgemeine Funktionen

==== Präsentation im Firefox 1.5.0.1 geht nicht ==== --HolgerR 11:50, 22. Feb 2006 (CET) Im Browserfenster wird nur der xml-Text dargestellt und nicht die Grafik.

--Hauke 12:26, 22. Feb 2006 (CET)

wie sind die weiteren rahmenbedingungen? ? OS? Adobe PlugIn zusaetzlich install.?
tritt dies auch bei anderen rechnern auf? (leider kann ich auch diesen bug nicht reproduzieren!)

--HolgerR 13:55, 22. Feb 2006 (CET)

Problem tritt nicht generell auf. Bei Zugang über Demoserver mit Firefox funzt es. Gehe ich über unseren lokalen Server, dann siehe oben

==== Verschieben/Pan ==== --HolgerR 11:50, 22. Feb 2006 (CET) Klick zum neuen Zentrieren der Karte funktioniert nur einmal, danach erst wieder nach Aufruf einer anderen Funktion. Im Hinblick auf die Nutzung der Suche nach Koordinaten (sehr gute Idee), um die Koordinaten des Kartenzentrums für andere Anwendungen herauszulesen sehr hinderlich.

--Hauke 12:21, 22. Feb 2006 (CET)

Ist mir leider nicht moeglich das zu reproduzieren! :-(

(tritt dieses verhalten auch bei anderen nutzern auf?)

--HolgerR 16:12, 22. Feb 2006 (CET)

Ja, ich war jetzt an 2 anderen Rechner, auch als anderer Nutzer, gleicher Effekt

--Markus Hentschel 07:38, 24. Feb 2006 (CET) Wenn mit "Klick zum neuen Zentrieren" das Verschieben der Bildmitte mittels Koordinateneingabe gemeint ist, dann kann ich den Fehler bei mir nicht nachvollziehen. Ich kann beliebig oft die Koordinateneingabe wiederholen und es funzt.

----HolgerR 10:45, 27. Feb 2006 (CET)

Es ist schon die PAN-Funktion gemeint, um mit einem Klick ein Objekt in die Mitte des Kartenausschnittes zu verschieben.

--Markus Hentschel 13:20, 27. Feb 2006 (CET)

Ja, jetzt ist es klar. War mir gar nicht bewußt, dass man mit der Pan-Funktion auch klicken kann. Der erste Klick zentriert den angeklickten Punkt in die Mitte. Weitere Klicks machen dann gar nichts, es sei dann, mann benutzt eine andere Zoomfunktion zwischendurch oder verschiebt mittels PAN "richtig".

Sachdatenanzeige Flurstück

--Markus Hentschel 12:17, 24. Feb 2006 (CET)

Es gibt zwei Snippets zur Sachdatenanzeige (Flurstücke.php und flurstuecksanzeige.php). Besser wäre, es gäbe nur eine Datei statt deren zwei. Die Beschriftung ist unlogisch: Während in der Flurstücke.php mit "ALB-Auszug 30" der Ausdruck ohne WZ gemeint ist, ist in der flurstuecksanzeige.php mit "ALB-Auszug 30" der Ausdruck mit WZ gemeint (für 35 dasselbe).

Suchfunktionen

==== Suche nach Adressen ==== --HolgerR 11:50, 22. Feb 2006 (CET) Das Feld --Auswahl-- im Straßenfeld steht an letzter Stelle. Für eine vereinheitlichte Bedienung und Darstellung auch hier an erster Stelle platzieren.

==== Suche nach Flurstücken ==== --HolgerR 11:50, 22. Feb 2006 (CET) Wenn eine Gemarkung nur eine Flur hat, springt das Pulldown-Menue für selbige nach Auswahl der Gemarkung gleich auf die 1 (das Gleiche erfolgt auch für Flurstücken in Fluren, die nur 1 Flurstück haben). Im Sinne der einheitlichen Darstellung und Handhabung können diese Automatismen entfallen.

==== Suche nach Namen ==== --HolgerR 11:50, 22. Feb 2006 (CET) Die Einschränkung des Suchergebnisses nach Gemarkung ergibt nicht das gewünschte Ergebnis. Die Namen werden doppelt aufgeführt und andere Einträge fehlen. Die Sucheinschränkung nach dem Grundbuchbezirk funktioniert dagegen einwandfrei.

Datenmangement

==== ALB-Änderung - Dateiauswahl - vorgeschlagener Dateiname ==== --HolgerR 11:50, 22. Feb 2006 (CET) Der in der config.php vereinbarte WLDGEFILENAME wird in der Auswahlmaske nicht angezeigt.

==== ALB-Änderung - Dateiauswahl - Standard-Auswahl ==== --HolgerR 11:50, 22. Feb 2006 (CET) PostgreSQL als Standard-DB aktiv setzten.

Nutzerverwaltung

==== Nutzer anlegen - zurücksetzen ==== --HolgerR 11:50, 22. Feb 2006 (CET) Das Feld berechtigte Stellen wird bei 'zurücksetzen' nicht geleert. Bei Neueingabe der Daten werden jedoch die noch angezeigten Stellen nicht in die Datenbank übernommen.

==== Nutzer anlegen - falsche Passwortbestätigung ==== --HolgerR 11:50, 22. Feb 2006 (CET) Das Feld berechtigte Stellen wird auch geleert. Dies ist so nicht notwendig, da ja nur Passwort verkehrt bestätigt wurde.

==== Nutzer anlegen - Rolleneintrag in Datenbank ==== --HolgerR 11:50, 22. Feb 2006 (CET) In der Tabelle user Spalte stelle_id wird standardmäßig die Stelle 1 eingetragen, auch wenn diese Stelle nicht in den berechtigten Stellen eingetragen wurde. Daraus resultiert beim erstmaligen Aufruf des neuen Nutzers ein Fehler bzgl. setExtent(): Given map extent is invalid Es muss sichergestellt werden, dass hier nur eine Stelle eingetragen wird, die auch dem User zugeordnet ist.

Nutzer anzeigen - ändern - Benutzerdaten Editor

--HolgerR 11:50, 22. Feb 2006 (CET) Änderung des Passwortes wird nicht übernommen – in user.php function Aendern($userdaten) Zeile 327 fehlerhaft: $useraten muss $userdaten heißen
- --Markus Hentschel 08:26, 1. Mär 2006 (CET) Wenn ich Nutzerdaten ändere, z.B. einen Layer hinzufüge, dann soll das Passwort nicht geändert werden. Wenn ich das richtig verstanden habe, muss ich dann bei "Auch Passwort ändern" keinen Haken setzen. Wenn ich das aber so mache und die Änderung speichere, kommt eine Meldung: "Passworteingabe und -wiederholung fehlt". Das dürfte so doch nicht gemeint sein?
--Markus Hentschel 07:25, 14. Mär 2006 (CET) Beim Ändern von Nutzerdaten werden in der u_groups2rolle die Einträge dupliziert. D.h. wenn ich z.B. einen Benutzer neu eingetragen habe und anschließend seine Nutzerdaten ändere, dann stehen in der u_groups2rolle alle Einträge zu diesem User doppelt drin.
- --Rahn 12:14, 14. Mär 2006 (CET)
  
  Theoretisch dürften die Einträge in u_groups2rolle nicht doppelt vorkommen, da user_id, stelle_id und id hier Primärschlüssel sind und die Funktion setGroups der Klasse rolle Eintragungen immer mit INSERT IGNORE vornimmt. Kann es sein, dass die drei Primärschlüssel nicht richtig gesetzt sind?
  - --Markus Hentschel 06:55, 17. Mär 2006 (CET) Es ist so, bei jeder Änderung über "Nutzer ändern" wird jeder Eintrag zu dem ausgewählten User noch einmal gemacht.

Antragsverwaltung

Anträge anzeigen

==== Anträge bearbeiten - Vermessungsart ==== --HolgerR 13:17, 22. Feb 2006 (CET) Im Fenster „Antrag bearbeiten“ wird unabhängig von der vergebenen Vermessungsart immer der 1. Eintrag, in unserem Fall „Bodenordnung“ präsentiert --> die zum Antrag abgespeicherte Vermessungsart muss angezeigt werden

==== Zugeordnete Dokumente Anzeigen - ohne hinterlegte Dokumente ==== --HolgerR 13:17, 22. Feb 2006 (CET) Es erfolgt folgende Fehlerausschrift:

Diesen Fehler bitte programmtechnisch auffangen.

==== Zugeordnete Festpunkte in KVZ-Schreiben - ohne ausgewählte Festpunkte ==== --HolgerR 13:17, 22. Feb 2006 (CET) erzeugt folgende Fehlerausschrift:

Serverfehler! Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Fehlermeldung: Premature end of script headers: php Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren Sie bitte den Webmaster hierüber. Error 500 10.32.0.246 Mon Feb 20 10:10:56 2006 Apache/2.0.49 (Linux/SuSE)

Diesen Fehler bitte programmtechnisch auffangen.

ALB-Ausdruck 30 und 35 als PDF

falsche Kopfanzeige

--Markus Hentschel 12:04, 24. Feb 2006 (CET)

Bei mir steht "Kataster/Vermessungsamt 0017 Landkreis Bad Doberan" im Ausdruck. Mach ich was falsch oder ist das fehlerhaft?

--HolgerR 10:50, 27. Feb 2006 (CET)

Markus, die Angaben zum Katasteramt sind fest in der alb.php eingetragen. Du kannst notfalls die Angaben dort ab Zeile 100 ändern. Sinnvoller ist es auf alle Fälle, wenn diese Angaben als Variable übergeben werden.

--Markus Hentschel 13:21, 27. Feb 2006 (CET)

Jou, hab ich schon gemacht. Und ja, muss auf alle Fälle in die config.php. Ich schreibs in die ToDo-Liste.

Trennlinie fehlerhaft

--Markus Hentschel 12:04, 24. Feb 2006 (CET)

Die durchgehende Trennlinie im oberen Bereich des ALB-Auszugs des DVZ fängt genau ein "-" vorher an.

--Rahn 13:23, 29. Mär 2006 (CEST)

In Version 1.5.9 behoben

Miteigentumsanteil

--Markus Hentschel 12:04, 24. Feb 2006 (CET)

Die Miteigentumsanteile müssen angezeigt werden

--Rahn 13:23, 29. Mär 2006 (CEST)

In Version 1.5.9 behoben

Zusätze

--Markus Hentschel 12:04, 24. Feb 2006 (CET)

Die Zusätze zur Bestandsblattnummer müssen angezeigt werden

"Bestand"-Abschnitte

--Markus Hentschel 12:04, 24. Feb 2006 (CET)

Der Bestand geht grundsätzlich nicht über den Seitenumbruch. Wenn ein Bestand nicht mehr vollständig auf die Seite passt, muss er komplett auf der nächsten Seite erscheinen.

Wasserzeichen

--Markus Hentschel 08:30, 10. Mär 2006 (CET)

Das Wasserzeichen erscheint nur auf der ersten Seite. Wenn der Ausdruck über mehrere Seiten geht, fehlt es auf allen nachfolgenden Seiten.

--Rahn 13:23, 29. Mär 2006 (CEST)

In Version 1.5.9 behoben

Nachweisverwaltung

Aufruf Rissrecherche

--HolgerR 11:10, 27. Feb 2006 (CET)

Der Aufruf der Rissrecherche erzeugt folgendes Fehlerfenster:

Laufzeitfehler in Mircrosoft JScript

Das Objekt unterstützt diese Eigenschaft oder Methode nicht.

line: 411, column: 2

Dieser Fehler tritt auch auf, wenn ich die Funktion vom Demo-Server nutze.

Aufruf Dokument einfügen

--HolgerR 11:10, 27. Feb 2006 (CET)

Der Aufruf der Rissrecherche erzeugt folgendes Fehlerfenster:

Laufzeitfehler in Mircrosoft JScript

Das Objekt unterstützt diese Eigenschaft oder Methode nicht.

line: 354, column: 2

Dieser Fehler tritt auch auf, wenn ich die Funktion vom Demo-Server nutze.

Exportfunktionen

PDF-Ausgabe

--HolgerR 12:55, 27. Feb 2006 (CET)

Der Aufruf der PDF-Ausgabe erzeugt folgende Fehlerausschrift:

Warning: getimagesize(): Read error! in /srv/www/htdocs/PDFClass/class.pdf.php on line 2833 Warning: Division by zero in /srv/www/htdocs/PDFClass/class.pdf.php on line 2850

Das Arcobat-Reader-Plugin wird im Internetexplorer gestartet und im angezeigten PDF-Dokument werden nur Fragmente dargestellt, die durch ab- und aufscrollen verschwinden.

Metadaten

Aufruf - Metadaten anlegen

--HolgerR 13:07, 27. Feb 2006 (CET) Der Aufruf zum Metadaten anlegen erzeugt folgendes Fehlerfenster:

Laufzeitfehler in Mircrosoft JScript

Das Objekt unterstützt diese Eigenschaft oder Methode nicht.

line: 160, column: 2

@@ Zeile 1: / Zeile 1: @@
+= Version 1.6.9 =
+== + Spaltenbreite für 'symbolname' in Tablle 'styles' zu gering ==
+--[[Benutzer:HolgerR|HolgerR]] 10:28, 14. Okt 2008 (CEST)<br>
+Bei der Umsetzung der Zeichenvorschrift aus der AG Web-GIS für die Darstellung der Liegenschaftskarte in kvwmap mittels der Definitionstabelle in MySQL ist mir aufgefallen, dass die Spaltenbreite für den Symbolnamen in der Tablle 'styles' zu gering ist, um z.B. den Symbolnamen 'mischwald_einzelne_nadelws' abzuspeichern. Um die Symbolnamen aus der Datei 'symbole.sym' 1:1 übernehmen zu können, ist die Breite auf 40 mit nachfolgendem SQL-Befehl zu vergrößern:
+ ALTER TABLE `styles` CHANGE `symbolname` `symbolname` VARCHAR( 40 ) CHARACTER SET latin1 COLLATE latin1_german1_ci DEFAULT NULL
+== + Keine Möglichkeit 'minwidth' und 'maxwidth' in die Tabelle 'styles' einzugeben ==
+--[[Benutzer:HolgerR|HolgerR]] 10:28, 14. Okt 2008 (CEST)<br>
+Die Werte 'minwidth' und 'maxwidth' für die Steuerung der Linienstärke können nicht in der Tabelle 'styles' eingegeben werden. Um die entsprechenden Felder der Tabelle hinzuzufügen, sind folgende SQL-Befehle für die MySQL-Datenbank auszuführen:
+ ALTER TABLE `styles` ADD `minwidth` INT( 11 ) DEFAULT NULL AFTER `width` ;
+ ALTER TABLE `styles` ADD `maxwidth` INT( 11 ) DEFAULT NULL AFTER `minwidth` ;
+Damit die Werte auch an das Mapfile übertragen werden, sind in der Datei 'kvwmap.php' in der Funktion 'loadMap' folgende Korrekturen vorzunehmen:
+*Für 'minwidth':
+'''alt'''
+ $style->minwidth = $dbStyle['minwidth']
+'''neu'''
+ $style-> set('minwidth',$dbStyle['minwidth']);
+*Für 'maxwidth':
+'''alt'''
+ $style->maxwidth = $dbStyle['maxwidth'];
+'''neu'''
+ $style-> set('maxwidth',$dbStyle['maxwidth']);
+== + Übergabe des Feldnames aus 'angleitem' an Mapdatei erfolgt nicht ==
+--[[Benutzer:HolgerR|HolgerR]] 10:01, 14. Okt 2008 (CEST)<br>
+Für die Mapserverversion kleiner 5.0 erfolgt die Übergabe des Feldnamens mit den Winkelangaben aus dem Feld 'angleitem' und die Übergabe eines Winkelwertes aus dem Feld 'angle' aus der Tabelle 'styles' nicht.
+Als Lösung schlage ich folgende Verfahrensweise vor. Die Datei Funktion 'loadMap' in der Datei ''kvwmap.php'' ist wie folgt zu editieren:
+*Löschen der Kommentartags '''/* ... */'''
+*Für die Einträge in dem Feld 'angle' ist die Zeile
+ $style->angle = (int)$dbStyle['angle'];
+mit folgender Schreibweise
+ $style -> set('angle',$dbStyle['angle']);
+zu ersetzen. Wenn in dem Feld 'angle' eine '0' steht, wird der Schlüssel nicht in die Mapdatei eingetragen. Bei 'angle' = 'NULL' erscheint in der Mapdatei der Eintrag ''ANGLE 360'', die winkelrichtige Darstellung bei der Verwendung von 'angleitem' erfolgt troztdem.
+*Die Übergabe des Feldnamens mit den Winkelangaben aus dem Feld 'angleitem' erreicht man durch das Ersetzen der Zeile
+ $style->angleitem = $dbStyle['angleitem'];
+mit dieser
+ $style -> set('angleitem',$dbStyle['angleitem']);
+In diesem Feld muss entweder kein Eintrag in der Datenbank od. halt der Feldbezeichner eingetragen sein. Ansonsten kommt es zum Abbruch beim Laden der Mapdatei - der Bildschirm bleibt weiß. Also, irgendwelche Zahlen sind an dieser Stelle mit 'NULL' zu ersetzen.
+Welche Anpassungen bei der Mapserverversion > 5.0 vorzunehmen sind weiß ich nicht. Hier wird der Feldbezeichner für das Feld mit den Winkeleinträgen zum Schlüsselwort 'angle' angegeben.
+*Bei dieser Gelegenheit kann dann auch gleich der Aufruf von 'maxsize' wie folgt korrigiert werden
+ $style -> set('maxsize',$dbStyle['maxsize']*$this->map_factor);
+*Und schließlich kann noch der Aufruf für 'width' ohne Berücksichtigung von 'map_factor' mit folgender Zeile ersetzt werden:
+ $style-> set('width',$dbStyle['width']);
+== + Darstellung von CARTOLINE funktioniert nicht ==
+--[[Benutzer:HolgerR|HolgerR]] 10:03, 7. Okt 2008 (CEST)<br>
+Wenn für die Ausgestaltung von Layern des Typs 'Polygon' in der ''symbole.sym'' für die Ausgestaltung der Linien der Type CARTOLINE definiert wird, werden diese nicht angezeigt.
+Um sich die Linien dennoch anzeigen zu lassen, darf in der Tabelle 'styles' das Feld 'color' nicht belegt sein. Damit jedoch bei leerem 'color'-Feld nicht der Wert '0 0 0' in das Mapfile übertragen wird, ist noch in der class-Datei ''kvwmap.php'' die function 'loadclasses' wie folgt anzupassen:<br>
+'''alt'''
+<pre>
+        $RGB=explode(" ",$dbStyle['color']);
+        $style->color->setRGB($RGB[0],$RGB[1],$RGB[2]);
+        $RGB=explode(" ",$dbStyle['outlinecolor']);
+        $style->outlinecolor->setRGB($RGB[0],$RGB[1],$RGB[2]);
+</pre>
+'''neu'''
+<pre>
+        if ($dbStyle['color']!='') {
+          $RGB=explode(" ",$dbStyle['color']);
+          $style->color->setRGB($RGB[0],$RGB[1],$RGB[2]);
+        }
+        if ($dbStyle['outlinecolor']!='') {
+          $RGB=explode(" ",$dbStyle['outlinecolor']);
+          $style->outlinecolor->setRGB($RGB[0],$RGB[1],$RGB[2]);
+        }
+</pre>
+Für eine kantengeglättete Darstellung der Cartolines sind folgenden Anpassungen notwendig [[weiter...]]. Da die Berechnungen der Kantenglättung sehr intensiv sind, verlängert sich die Zeit für die Aufbereitung, Übertragung und Darstellung der Karte.
+== + Kartenausschnitt nach Layersuche ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 10:54, 12. Sep 2008 (CEST) Wenn man in der Layersuche nach einem Datensatz sucht, dessen Geometrie außerhalb des max. Extents der Stelle liegt, dann zoomt kvwmap trotzdem dahin. Es müsste aber eine entsprechende Meldung kommen.
+== + Ausrichtung Nordpfeil ==
+--[[Benutzer:HolgerR|HolgerR]] 08:37, 30. Jul 2008 (CEST) <br>
+Der Nordpfeil wird in der Druckausgabe bei Angabe eines Drehwinkels nicht gedreht. Ich nutze PHP in der Version 4.3.10 mit der internen GD-Bibliothek.
+:--[[Benutzer:Rahn|Rahn]] 09:36, 31. Jul 2008 (CEST) Der Nordpfeil wird direkt im PDF erzeugt, d.h. er hat nichts mit GD zu tun. Eigentlich sollte das funktionieren. Ist der Pfeil vielleicht Teil des Hintergrundbildes?
+::--[[Benutzer:HolgerR|HolgerR]] 09:52, 31. Jul 2008 (CEST) sri. Genau. Der Pfeil ist Teil des Hintergrundbildes. Ist alles schon eine Weile her, als ich die Druckvorlagen erzeugt hatte.
+== + Flurstücksdatenanzeige| Aktualität der ALK-Daten ==
+--[[Benutzer:Hschmidt|Hschmidt]] 08:51, 21. Jul 2008 (CEST)<br>
+Bei der Anzeige der Flurstücksdaten wird die Aktualität der Flurstücksdaten offenbar aus der Tabelle edbsdatei geholt. Diese sollte aber aus der Tabelle edbsauftrag aus der Spalte auftaktu stammen. War das nicht schon mal so?
+Es wird erst versucht, das Datum aus der ''edbsauftrag'' zu holen und wenn das nicht da ist, aus der ''edbsdatei''.
+== - labelangleitem unter Mapserver 5.0.2 ==
+--[[Benutzer:HolgerR|HolgerR]] 16:37, 17. Jul 2008 (CEST) <br>
+Die Hausnummern der Gebäude werden unter dem Mapserver 5.0.2 nicht entsprechend der Winkelangaben in PostgreSQL ausgerichtet. Kann es sein, dass bei der Änderung von Mapserver 4.x nach 5.x hinsichtlich von Labelangleitem diese nicht nach Mapscript portiert worden sind?
+:--[[Benutzer:Rahn|Rahn]] 10:16, 18. Jul 2008 (CEST) Sieht ganz danach aus. Wenn man sich das erzeugte savemapfile.map ansieht, steht beim entsprechenden Layer bei ANGLE 0.000000. Scheint also so, als wenn das Labelangleitem nicht interpretiert wird.
+:--[[Benutzer:HolgerR|HolgerR]] 10:25, 18. Jul 2008 (CEST) Ja, im Prinzip wird Labelangleitem nicht mehr layerweit angewandt. Statt dessen kann ich in der Sektion Label dem Winkel einen Wert aus einer Tabelle übergeben: '''angle [winkel]'''. Mittels Mapscript kann man an angle aber nur Zahlen übergeben. Ich sehe hier 2 Möglichkeiten:
+:* Mapscript dazu bringen, dass hier auch alphanumerische Angaben möglich sind
+:* kvwmap so umstricken, dass gleich die entsprechenden numerischen Werte an angle übergeben werden
+: In 'kvwmap.php' wird an angle der Eintrag aus der mysql-Tabelle 'layer', hier 'winkel', richtig übertragen. Es ist halt nur keine Zahl, sondern der Feldbezeichner.
+:--[[Benutzer:Rahn|Rahn]] 15:34, 18. Jul 2008 (CEST) Ich denke, es dauert nur noch eine Weile, dann geht das auch mit PHPMapscript. Die Variante den Winkel selber aus der Postgres-DB auszulesen ist glaube ich zu aufwendig.
+:--[[Benutzer:HolgerR|HolgerR]] 07:03, 21. Jul 2008 (CEST) Stefan, kannst du das Problem in die Bug-Liste zum PHP-Mapscript reinstellen oder steht das da schon drin? Ich habe noch nichts entsprechendes gefunden.
+== - PostgreSQL 8.3.x - WHERE mit unterschiedlichen Datentypen ==
+--[[Benutzer:HolgerR|HolgerR]] 08:43, 11. Jul 2008 (CEST) <br>
+Ich habe gerade einen Server mit der aktuellsten PostgreSQL-Version (8.3.3) aufgesetzt. Hierbei gibt es jedoch Probleme bei Abfragen, in denen in der WHERE-Klausel Daten unterschiedlichen Typs verglichen werden, z.B. beim Flurstückslayer im pfad-Statement:
+ ...
+ FROM alknflst as alkf, alkobj_e_fla AS alko, alb_v_gemarkungen as gemkg
+ WHERE alko.folie='001' AND alko.objnr = alkf.objnr AND gemkg.gemkgschl=alkf.gemkgschl
+Der Gemarkungsschlüssel 'gemkgschl' aus der Tabelle 'alknflst' ist vom Typ '''character varying(6)''' und aus der Tabelle 'alb_v_gemarkungen' vom Typ '''integer'''.
+In PostgreSQL wird folgende Fehlerausschrift erzeugt:
+<pre>
+ERROR:  operator does not exist: integer = character varying
+LINE 1: ...1' AND alko.objnr = alkf.objnr AND gemkg.gemkgschl=alkf.gemk...
+                                                             ^
+HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.
+********** Fehler **********
+ERROR: operator does not exist: integer = character varying
+SQL Status:42883
+Hinweis:No operator matches the given name and argument type(s). You might need to add explicit type casts.
+Zeichen:1513
+</pre>
+Siehe hierzu auch die Versionshinweise von PostgreSQL zu [http://www.postgresql.org/docs/8.3/static/release-8-3.html Release-8.3]
+Hieraus ergeben sich nun m.E. 2 Möglichkeiten auf die Weiterentwicklung von PostgreSQL zu reagieren:
+# Überarbeiten der Datenbankstruktur und ev. Anpassen der SQL-Statements
+# Anpassen der SQL-Statements, in denen unterschiedlichen Dateitypen verglichen werden in der Form
+::gemkg.gemkgschl::text=alkf.gemkgschl::text
+::bzw. - SQL-konform
+::CAST(gemkg.gemkgschl AS text)=CAST(alkf.gemkgschl AS text)
+Darüber hinaus sollte vorerst auf den Einsatz der Version 8.3.x von PostgreSQL verzichtet werden.
+::--[[Benutzer:Markus Hentschel|Markus Hentschel]] 15:01, 29. Jan 2009 (CET) Bei vielen Layern und Abfragen kann alles beim Alten bleiben. Hier eine Sammlung der Abfragen, die geändert werden müssen: [[Geänderte SQL-Abfragen bei Upgrade auf PostgreSQL 8.3.x]]
+== + Generischer Layereditor - Geometrie hinzufügen ohne Geometrie ==
+--[[Benutzer:HolgerR|HolgerR]] 15:48, 9. Jul 2008 (CEST) <br>
+Wird zum Geometrie hinzufügen bzw. entfernen ein Layer ausgewählt, der nicht flächendeckend vorliegt, wird bei einem Klick in einen leeren Bereich des Layers in der Flächenanzeige folgender Fehler angezeigt:
+<pre><br><b>Fehler bei SQL Anweisung:<br>SELECT round(Area(GeomFromText('\'))::numeric, 2)<br></b>\</pre>
+und die Bearbeitung wird abgebrochen.
+== - Generischer Layereditor - Geometrie hinzufügen - Fehler bei 'ORDER BY - Klausel' in Data ==
+--[[Benutzer:HolgerR|HolgerR]] 15:48, 9. Jul 2008 (CEST) <br>
+Zur Darstellung der zeitlich richtigen Reihenfolge von Objekten machte es sich erforderlich, in der Layerdefinition eine Sortieranweisung für die Daten in der Form ''SELECT * FROM data WHERE objnr > 1 ORDER BY datum'' zu vereinbaren.
+Wird dieser Layer im Generischen Layereditor ausgewählt, um Geometrie hinzuzufügen oder zu entfernen, wird in der Flächenanzeige folgender Fehler angezeigt:
+<pre> <br><b>Fehler bei SQL Anweisung:<br>SELECT round(Area(GeomFromText('\'))::numeric, 2)<br></b>\ </pre>
+Obiges SELECT-Statement in ein View gepackt, funktioniert.
+Nun soll ja nicht immer ein View vereinbart werden. Gibt es die Möglichkeit, solche Statements entsprechend umzusetzen?
+== + Tabelle u_menues Spalte order ==
+--[[Benutzer:HolgerR|HolgerR]] 09:47, 7. Jul 2008 (CEST) <br>
+In den Dateien 'mysql_install.sql' und 'mysql_update.sql' ist als neue Spalte für die Standardsortierung der Menüs die Spalte '''order''' eingefügt worden. Dies ist in SQL ein reserviertes Wort. Beim Ausführen der Dateien bekomme ich hier eine Fehlerausschrift und die Abarbeitung der SQL-Statements wird abgebrochen.
+Entweder müsste der Spaltenbezeichner in Anführungszeichen ( `bezeichner` ) gesetzt werden oder halt umbenannt werden.
+--[[Benutzer:Rahn|Rahn]] 09:58, 7. Jul 2008 (CEST) Aber die Spaltenbezeichnung steht doch in Hochkommas...?
+ # Hinzufügen einer neuen Spalte für die Sortierung der Menüs
+ ALTER TABLE `u_menues` ADD `order` INT( 11 ) NOT NULL DEFAULT '0';
+ CREATE TABLE u_menues (
+  id int(11) NOT NULL auto_increment,
+  `name` varchar(100) NOT NULL default '',
+  `name_english_windows-1252` VARCHAR(100) CHARACTER SET cp1250 COLLATE cp1250_general_ci NULL,
+  `name_vietnamese_utf-8` VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL,
+  links varchar(255) NOT NULL default '',
+  obermenue int(11) NOT NULL default '0',
+  menueebene tinyint(4) NOT NULL default '1',
+  target varchar(10) default NULL,
+  `order` INT(11) NOT NULL DEFAULT '0',
+  PRIMARY KEY  (id)
+ ) TYPE=MyISAM;
+:--[[Benutzer:HolgerR|HolgerR]] 10:06, 7. Jul 2008 (CEST)
+:So ist das i.O. :) Bei mir war '''order''' in der Datei 'mysql_install.sql' nicht in accent grave eingeschlossen, deshalb die Fehlermeldung.
+== + Fehlermeldung wenn ein Nutzer keiner Stelle zugeordnet ist ==
+--[[Benutzer:Hschmidt|Hschmidt]] 10:02, 23. Jun 2008 (CEST) <br>
+Wenn ein Nutzer, der keiner Stelle zugeordnet ist, versucht sich einzuloggen kommt eine Fehlermeldung:
+ ... Richten Sie mit phpMyAdmin in der kvwmap Datenbank eine Referenzkarte, ein Stelle, einen Benutzer und eine Rolle ein!(Tabellen referenzkarten, stelle, user, rolle)
+Hier wäre es sinnvoll diesen Fall mit einer Meldung abzufangen, z.B. "Sie haben z. Zt. keinen Zugriff auf eine Arbeitsstelle, bitte wenden Sie sich an ihren Systemverwalter!" o.ä. <br>
+Kommt zwar selten vor, aber ...
+== +- Einf&auml;rbung gesuchter Objekte ==
+--[[Benutzer:HolgerR|HolgerR]] 08:52, 23. Jun 2008 (CEST) <br>
+Ich hatte versucht die Layerbezeichnungen, Classes, Styles und Labels zu systematisieren und entsprechende ID's zuzuordnen. Dabei bin ich über den Integerwert von 2.147.483.647 für Classes, Styles und Labels gekommen.
+Als Resultat dieser Wert&uuml;berschreitung wird das gesuchte Objekt nicht mehr gelb in der Karte dargestellt. Muss ich mit dieser Einschr&auml;nkung leben und die ID-Werte wieder verringern oder gibt es M&ouml;glichkeiten, dieses zu umgehen?
+--[[Benutzer:Rahn|Rahn]] 13:38, 23. Jun 2008 (CEST) Man könnte den Datentyp der IDs anpassen. Entweder macht man aus dem INT ein UNSIGNED INT, dann hat man nochmal den Bereich bis 	4.294.967.295 zur Verfügung. Oder man nimmt BIGINT, dann geht's bis maximal 18.446.744.073.709.551.615 (siehe [http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html MySQL-Dokumentation]).
+:--[[Benutzer:HolgerR|HolgerR]] 13:56, 23. Jun 2008 (CEST) Das habe ich schon versucht, die IDs in classes, styles und rollenlayer haben den Typ BIGINT mit 12 Stellen. In der Tabelle 'rollenlayer' wird jedoch in der Spalte 'class_id' ein Wert unabhängig von der ID in der tabelle 'classes' inkrementell eingetragen. In der Tabelle 'u_styles2classes' werden in den Spalten 'class_id' und 'style_id' auch inkrementelle Werte eingetragen, die mit den Werten in den Tabellen 'classes' und 'styles' nicht übereinstimmen.
+:Könnte das vielleicht mit PHP und dem Betriebssystem zusammenhängen? (siehe [http://www.php.net/manual/de/language.types.integer.php PHP-Integer_Referenz]).
+:--[[Benutzer:Rahn|Rahn]] 14:26, 23. Jun 2008 (CEST) Es liegt wohl an der verwendeten mysql_insert_id() Funktion. Auf der Seite in der [http://de3.php.net/manual/de/function.mysql-insert-id.php PHP-Dokumentation] steht nämlich eine entsprechende Warnung.
+== + Firefox 3 - Werkzeugleiste ==
+--[[Benutzer:HolgerR|HolgerR]] 11:13, 20. Jun 2008 (CEST) <br>
+Seit vorgestern steht der Firefox 3 zum Download bereit. Erste Tests haben ergeben, dass die Werkzeugleiste nicht mehr so funktioniert wie gewohnt. Buttons,
+die eine Aktion auslösen, wie z.B. Gesamtansicht, funktionieren wie gehabt. Die anderen Funktionsbutton werden mit einem Anklicken nicht mehr aktiviert, der Focus springt vom gewünschten Button wieder auf den letzten aktiven Button zurück. Wird der Mauszeiger jedoch vom zu aktivierenden Button mit gedrückter linker Maustaste in das Kartenfenster gezogen, erhält dieser Button den Fokus und die Funktion kann wie gewohnt ausgeführt werden.
+--[[Benutzer:Rahn|Rahn]] 13:23, 23. Jun 2008 (CEST) Um den Fehler zu beheben, müssen in den Dateien SVG_map.php und SVG_druckausschnittswahl.php die Zeilen
+ <a xlink:href="">
+und
+ </a>
+gelöscht werden.
+Das gleiche gilt für die Datei SVG_Utilities.php. Hier darf aber nicht die ganze Zeile
+ <a xlink:href="">';
+gelöscht werden, das
+ ';
+muss stehen bleiben.
+:*--[[Benutzer:Markus Hentschel|Markus Hentschel]] 08:42, 25. Jun 2008 (CEST) Geht es dann noch mit Firefox 2 oder ist diese Änderung nur für die, die mit firefox 3 arbeiten?
+:*--[[Benutzer:Rahn|Rahn]] 09:58, 25. Jun 2008 (CEST) Nö, das sollte auch im Firefox 2 funktionieren.
+:*--[[Benutzer:Markus Hentschel|Markus Hentschel]] 10:37, 25. Jun 2008 (CEST) Jau, tuts.
+== + Antraganzeige - Zugeordnete Festpunkte in KVZ Schreiben ==
+--[[Benutzer:HolgerR|HolgerR]] 11:08, 19. Jun 2008 (CEST) <br>
+Wird in der Antragsanzeige 'Zugeordnete Festpunkte in KVZ Schreiben' ausgew&auml;hlt, ohne einen Antrag auszuw&auml;hlen, wird der Programmlauf abgebrochen. Um diesen Fehler abzufangen, sind die Dateien '''index.php''' und '''kvwmap.php''' wie folgt anzupassen:
+index.php - case 'Antraganzeige_Festpunkte_in_KVZ_schreiben' durch folgende 4 Zeilen ersetzen:
+   case 'Antraganzeige_Festpunkte_in_KVZ_schreiben' : {
+     $GUI->festpunkteInKVZschreiben();
+     $GUI->Antraege_Anzeigen();
+   } break;
+kvwmap.php - function festpunkteInKVZschreiben() mit nachfolgenden Code ersetzen
+<pre>
+  function festpunkteInKVZschreiben() {
+#19.06.2008, H.Riedel; Abfrage, ob Antrag ausgewaehlt wurde
+    if ($this->formvars['antr_selected']=='') {
+      $this->Fehlermeldung= '<br>W&auml;hlen Sie eine Antragsnummer aus!';
+    }
+    else {
+      $festpunkte=new Festpunkte('',$this->pgdatabase);
+      $ret=$festpunkte->createKVZdatei($this->formvars['antr_selected']);
+      if ($ret[0]) {
+        $this->Fehlermeldung=$ret[1];
+      }
+      else {
+        $this->Meldung=$ret[1];
+      }
+    }
+  }
+</pre>
+== + Dokumentenrecherche über Individuelle Nummer oder Antragsnummer :-( ==
+--[[Benutzer:Hschmidt|Hschmidt]] 10:13, 11. Jun 2008 (CEST)<br>
+Die Dokumentenrecherche über Individuelle Nummer oder Antragsnummer funktioniert nur in Verbindung mit einem Such-Polygon ansonsten kommt kommt die Meldung:
+ Geben sie ein Polygon an.
+Eine reine Suche nach Sachdaten ist nicht möglich.
+:--[[Benutzer:HolgerR|HolgerR]] 07:45, 30. Jul 2008 (CEST)
+:Im Snippet 'dokumenteneingabeformular.php' muss die Funktion 'save()' angepasst werden. Da muss irgenwie rein, dass nur bei der Suche nach 'Suchpolygon/-fenster' auf Vorhandensein eines Polygons getestet wird.
+== + Notizen erstellen ==
+--[[Benutzer:Varchmin|Varchmin]] 18:13, 10. Jun 2008 (CEST)
+Wenn man im Notizenformular eine Flächennotiz erstellen will, kommt beim klicken in die Karte mit dem Werkzeug "Polygon hinzufügen" folgender '''Laufzeitfehler in Microsoft JScrip''':
+ 'topt.document.GUI.lastcoordx' ist NULL oder kein Objekt line:601, column:2
+--[[Benutzer:Rahn|Rahn]] 08:56, 11. Jun 2008 (CEST) Um den Fehler zu beheben, müssen in der Datei SVG_polygon_xor_point.php nach der Zeile
+ <input name="last_doing" type="hidden" value="<? echo $this->formvars['last_doing']; ?>">
+diese beiden Zeilen eingefügt werden:
+ <input name="lastcoordx" type="hidden" value="">
+ <input name="lastcoordy" type="hidden" value="">
+--[[Benutzer:Varchmin|Varchmin]] 10:13, 11. Jun 2008 (CEST) Super! Problem behoben!
+== - vorherige Ansicht / naechste Ansicht im Kartenfenster ==
+--[[Benutzer:Hschmidt|Hschmidt]] 09:11, 9. Jun 2008 (CEST)<br>
+Die beiden Buttons "vorherige Ansicht / naechste Ansicht" im Kartenfenster funktionieren nicht mehr :-(
+:--[[Benutzer:Rahn|Rahn]] 14:16, 9. Jun 2008 (CEST) Hmmm, bei mir tun sie's. Inwiefern äußert sich das? Passiert gar nichts, oder lädt die Seite neu und der Kartenausschnitt stimmt nicht?
+== + Dokumentenrecherche über Polygon ==
+--[[Benutzer:Hschmidt|Hschmidt]] 14:50, 5. Jun 2008 (CEST)<br>
+Die Dokumentenrecherche über Polygon geht nicht mehr und in der Fehlerkonsole vom Firefox wird folgende Meldung abgelegt:
+ Fehler: top.document.GUI.lastcoordx has no properties Quelldatei: http://10.130.16.92/tmp/553264SVG_dokumentenformular.svg Zeile: 572
+--[[Benutzer:Rahn|Rahn]] 08:49, 6. Jun 2008 (CEST) Um den Fehler zu beheben, müssen in der Datei SVG_polygon_box_area.php nach der Zeile
+ <input name="last_doing" type="hidden" value="<? echo $this->formvars['last_doing']; ?>">
+diese beiden Zeilen eingefügt werden:
+ <input name="lastcoordx" type="hidden" value="">
+ <input name="lastcoordy" type="hidden" value="">
+--[[Benutzer:Hschmidt|Hschmidt]] 09:04, 9. Jun 2008 (CEST)<br>
+so läufts :-) Danke!
+== + GLE | nachträgliches Erfassen von Punktgeometrien ==
+--[[Benutzer:Hschmidt|Hschmidt]] 10:14, 3. Jun 2008 (CEST)<br>
+Das nachträgliche Erfassen von Geometrien im GLE ist bei Punktdaten schwierig.<br>
+Folgendes Beispiel: in einer Tabelle sind Sachdaten vorhanden und die Geometrie in Form eines Punktes soll nachträglich erfasst werden.
+Es wird im Kartenfenster der entsprechende Ausschnitt, wo der Punkt digitalisiert werden soll ausgewählt. Der Datensatz wird über die Layersuche selektiert und bei Aufruf der Geometriebearbeitung erscheint ein weisses Bild und der voreingestellte Kartenausschnitt wird verlassen.<br>
+Das gleiche Beispiel bei der Nacherfassung von Polygonen funktioniert jedoch.
+== - Filterverwaltung ==
+--[[Benutzer:Hschmidt|Hschmidt]] 15:13, 20. Mai 2008 (CEST)<br>
+Beim Versuch in der Filterverwaltung ein Polygon abzuspeichern kommt folgende Fehlermeldung:
+ Warning: pg_query() [function.pg-query]: Query failed: ERROR: unterminated quoted string at or near "'01060000205E0900000100000001030000000100000006000000B487CF006BD350413165AD8E10955641CC1976B573D350419A684A7517955641C05E73B97BD3504199AF72B0139556410F3333FB7AD35041D0AA63020E955641D6F0198670D350412C56C7140A955641B487CF006BD3504131, 2398)" at character 158 in /usr/local/httpd-2.2.3/htdocs/kvwmap-1.6.9/class/postgresql.php on line 3913
+ Fehler bei SQL Anweisung: SELECT geomfromtext('POLYGON((4410782.6 5919764.1, 4410876.4 5919764.1, 4410876.4 5919857.9, 4410782.6 5919857.9, 4410782.6 5919764.1))', 2398) && TRANSFORM('01060000205E0900000100000001030000000100000006000000B487CF006BD350413165AD8E10955641CC1976B573D350419A684A7517955641C05E73B97BD3504199AF72B0139556410F3333FB7AD35041D0AA63020E955641D6F0198670D350412C56C7140A955641B487CF006BD3504131, 2398)
+Die gleiche Aktion läuft unter der Version 1.6.7 fehlerfrei. Bei einfachen Polygonen bis zu 4 Stützpunkten gibt es auch keinen Fehler.
+= Version 1.6.8 =
+== + Hausnummernsortierung in Adresssuche ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:41, 30. Jun 2008 (CEST) In der Adresssuche werden die Hausnummern alphanummerisch sortiert, obwohl sie nummerisch sortiert sein sollten. Das war doch schon mal anders, oder?
+== + Suchergebnis nach Flurstückssuche ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 11:25, 30. Jun 2008 (CEST) Wenn man nach einem Flurstück gesucht hat, erscheint es zweimal in der Gruppe Suchergebnis.
+== + auseinandergezogene Menüs ==
+--[[Benutzer:Certa|Certa]] 11:27, 13. Jun 2008 (CEST) Die Menüs auf der linken Seite werden auseinander gezogen, wenn die Seite sehr lang wird. Eigentlich müssten die Menüpunkte am oberen Rand der Seite bleiben.
+== + Laufzeitfehlermeldung bei Koordinatenzoom ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 09:50, 28. Mai 2008 (CEST) Wenn man den Button Koordinatenzoom wählt und das Extrafenster anschließend wieder schließt, kommt eine Fehlermeldung "JScript Laufzeitfehler", die sich nicht wegklicken lässt.
+--[[Benutzer:Rahn|Rahn]] 11:24, 16. Jun 2008 (CEST) Um den Fehler zu beheben, muss in der Datei SVGvars_coordscript.php folgende Funktion ausgetauscht werden:
+ <nowiki>
+ function coords_input(){
+ 	if(scale < 0.01){
+ 		stellen = 2;
+ 	}
+ 	else if(scale < 0.1){
+ 			stellen = 1;
+ 	}
+ 	else{
+ 		stellen = 0;
+ 	}
+ 	mittex = format_number(mittex, stellen);
+ 	mittey = format_number(mittey, stellen);
+ 	coords1 = prompt("Geben Sie die gewünschten Koordinaten ein",mittex+" "+mittey);
+ 	if(coords1){
+ 		coords2 = coords1.split(" ");
+ 		if(!coords2[0] || !coords2[1]){
+ 			alert("Falsches Format");
+ 			return;
+ 		}
+ 		//coords[0] = (Number(coords[0])-minx)/scale;		Weltkoordinaten übergeben
+ 		//coords[1] = (maxy-Number(coords[1]))/scale;
+ 		document.GUI.INPUT_COORD.value = coords2[0]+","+coords2[1];
+		document.GUI.CMD.value = "jump_coords";
+ 		document.GUI.submit();
+ 	}
+ }
+ </nowiki>
+== + Mittelpunkt setzen mit Pan geht nur einmal ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 09:50, 28. Mai 2008 (CEST) Wenn man den Verschiebebutton auswählt und dann in die Karte klickt, wird der angeklickte Bildpunkt neuer Bildmittelpunkt. Das funktioniert allerdings nur beim ersten Mal, wenn man das noch mal macht, wird der Bildschirmausschnitt nicht verschoben.
+== + CSV-Export Flurstücke ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:45, 29. Apr 2008 (CEST) Wenn man einen CSV-Export bei Flurstücken oder historischen Flurstücken macht, fehlen die Attribute status und nachfolger. Dafür wird die WKT-Geometrie in the_geom mit ausgegeben, was unnötig ist.
+== + Geometrie-Editor - Geometrieübernahme ==
+--[[Benutzer:HolgerR|HolgerR]] 09:13, 25. Apr 2008 (CEST) Im Geometrieeditor ist das Übernehmen von Geometrien nicht möglich. Nach Auswahl des Werkzeuges 'Geometrie hinzufügen' wird beim ersten Klick in die Karte im Feld 'Fläche' folgender Eintrag generiert:
+<pre>
+ <br><b>Fehler bei SQL Anweisung:<br>SELECT round(Area(GeomFromText('\\'))::numeric, 2)<br></b>\
+</pre>
+In der php-Logdatei werden folgende Einträge generiert:
+ [25-Apr-2008 09:16:34] PHP Warning:  pg_query(): Query failed: ERROR:  Invalid OGC WKT (too short)
+ CONTEXT:  SQL function &quot;geomfromtext&quot; statement 1 in /srv/www/htdocs/kvwmap/class/postgresql.php on line 3907
+ [25-Apr-2008 09:16:34] PHP Warning:  pg_query(): Query failed: ERROR:  Invalid OGC WKT (too short)
+ CONTEXT:  SQL function &quot;geomfromtext&quot; statement 1 in /srv/www/htdocs/kvwmap/class/postgresql.php on line 3907
+ [25-Apr-2008 09:16:35] PHP Warning:  pg_query(): Query failed: ERROR:  Invalid OGC WKT (too short)
+ CONTEXT:  SQL function &quot;geomfromtext&quot; statement 1 in /srv/www/htdocs/kvwmap/class/postgresql.php on line 3907
+In der debug-Datei sind folgende Einträge erfolgt:
+<pre>
+<br><br><b>Anwendungsfall go: spatial_processing</b>
+<br><p>file:kvwmap class:db_mapObj->getlayerdatabase - Lesen des connection-Strings des Layers:<br>SELECT `connection` FROM layer WHERE Layer_ID = 630301
+<br><br>Datenbankverbindung öffnen: Datenbank: kvwmap User: user Passwd: passwort
+<br>Datenbank mit Connection_ID: Resource id #53 geöffnet.
+<br><br><b>Fehler bei SQL Anweisung:<br>SELECT round(Area(GeomFromText('\\'))::numeric, 2)<br></b>
+<br><br>MySQL Verbindung mit ID: Resource id #41 schließen.
+<br><br>PostgreSQL Verbindung mit ID: Resource id #53 schließen.
+</pre>
+Das Hinzufügen von Geometrien und die weitere Bearbeitung der bisherigen Geometrie ist anschließend nicht mehr möglich. Nach Betätigen des Button 'Polygon Löschen' wird der Eintrag aus dem Feld 'Fläche' gelöscht und  die Geometrie kann über 'Polygon hinzufügen', 'Polygon ausschneiden' und 'Eckpunkte bearbeiten' hinzugefügt bzw. geändert werden.
+Ich nutze PostgreSQL 8.1.9 mit PostGIS in der Version 1.1.7 (USE_GEOS=1 USE_PROJ=1 USE_STATS=1), PHP Version 4.3.10, Proj 4.6.0, Geos 3.0.0, Mapserver 4.10.3
+:--[[Benutzer:Rahn|Rahn]] 11:11, 25. Apr 2008 (CEST) Vielleicht ne dumme Frage, aber einen Geometrieabfragelayer hast Du auch ausgewählt, oder?
+:--[[Benutzer:HolgerR|HolgerR]] 12:56, 25. Apr 2008 (CEST) Stefan, wann ist ein Layer ein Geometrieabfragelayer. Darf die Geometrie aus mehreren Datenbanktabellen zusammengesetzt sein oder geht das nur über einen Layer/View, der in der 'geometry_columns' steht ? Der "klassische" Flurstückslayer geht bei mir nicht, jedoch ein Geometrielayer mit nur einer Tabelle in der DATA-Deklaration.
+:--[[Benutzer:Rahn|Rahn]] 15:29, 25. Apr 2008 (CEST) Ein Geometrieabfragelayer kann auch auf mehrere Tabellen zugreifen. Wichtig ist, dass es unter allen Tabellen nur ein 'the_geom' gibt. Wenn es mehrere 'the_geom' Spalten gibt, muss man durch qualifizierte Bezeichner festlegen, welches 'the_geom' für die Geometrieabfrage verwendet werden soll. Beim Layer Flurstücke gibt es 2 'the_geom' (einmal in alkobj_e_fla und einmal in alkobj_t_pkt), deswegen muss man das Data-Statement anpassen: [[Bug_kvwmap#.2B_Generischer_Layereditor_.7C_Geometrieabfrage-Layer:_Flurstuecke|Klick]]
+:--[[Benutzer:HolgerR|HolgerR]] 13:18, 28. Apr 2008 (CEST) Ich habe den Flurstückslayer so wie unten beschrieben abgeändert ... leider ohne Erfolg :( Die Fehlermeldungen sind noch die gleichen.
+::--[[Benutzer:HolgerR|HolgerR]] 07:24, 30. Apr 2008 (CEST) Ich habe jetzt das DATA-Statement so weit runtergebrochen, dass da nur noch SELECT * FROM tabelle steht und dann funktioniert es. Sobald allerdings im SQL-Statement in der WHERE-Klausel auf einen Text bezug genommen wird, hier '''WHERE folie='001'''', dann kann ich die Geometrie von diesem Layer nicht mehr übernehmen. Integer in der WHERE-Klausel sind kein Problem. Es müsste m.E. an den Hochkommatas, mit denen der Text eingeschlossen ist liegen. Wird das ganze Statement in ein View gepackt und dann das View im DATA-Statement angesprochen, funktioniert es.
+:--[[Benutzer:Rahn|Rahn]] 11:17, 30. Apr 2008 (CEST) Problem gelöst. Es lag [[Bug_kvwmap#.2B_Stellenauswahl|hier]] dran.
+== + Fehlermeldung bei Login-Fehler ==
+--[[Benutzer:Hschmidt|Hschmidt]] 10:39, 24. Apr 2008 (CEST)<br>
+Kein Fehler dieser Version, aber bei fehlerhaftem Login passiert einfach nichts :-( Wünschenswert wäre eine Fehlermeldung, sonst sind die Anwender oft verwirrt.
+== + Nachweisverwaltung - Rechercheergebnis - Nachweise Löschen ==
+--[[Benutzer:HolgerR|HolgerR]] 10:31, 22. Apr 2008 (CEST) Der Aufruf für die Anzeige des Löschbutton erfolgte bis zur Version 1.6.5 im Snippet 'nachweisanzeige.php' über:
+ <? if($this->Stelle->isFunctionAllowed('Nachweisloeschen')){ ?>
+Seit der Version 1.6.6 lautet der Aufruf aber
+ <? if($this->Stelle->isFunctionAllowed('Nachweiseloeschen')){ ?>
+Damit wird der Löschbutton nicht mehr angezeigt. In der Datei 'index.php' heißt die Funktion 'Nachweisloeschen', so ist sie auch in der MySQL-DB in der Tabelle 'u_funktionen' hinterlegt. Handelt es sich hierbei nur um einen Tippfehler im Snippet oder muss die Tabelle 'u_funktionen' um den Eintrag 'Nachweiseloeschen' erweitert werden?
+--[[Benutzer:Rahn|Rahn]] 11:32, 22. Apr 2008 (CEST) Das Problem hatten wir letztes Jahr schonmal: [[Bug_kvwmap#.2B_Nachweisverwaltung_-_Nachweise_l.C3.B6schen|Klick]]. Aber offenbar gibt es immernoch Unterschiede in der Schreibweise zwischen der index.php in dem Snippet. Deshalb wird jetzt alles in "'''Nachweisloeschen'''" geändert.
+*In der index.php steht es ja schon so.
+*Dann muss es eine Funktion "Nachweisloeschen" geben, die den jeweiligen Stellen zugeordnet ist.
+*Und das Snippet muss angepasst werden, also in der oben genannten Zeile muss es "Nachweisloeschen" heißen.
+:--[[Benutzer:HolgerR|HolgerR]] 12:32, 22. Apr 2008 (CEST) Sri, das nächste Mal muss ich dann wohl doch intensiver die Bugliste studieren. Der Eintrag in der mysql_install_help.sql - Datei passt dann auch zum Vorschlag von Stefan.
+== + Festpunkte Sachdatenanzeige - kein Sprung auf Punkt ==
+--[[Benutzer:HolgerR|HolgerR]] 13:30, 21. Apr 2008 (CEST) Die Anzeige des Festpunkte im Kartenfenster aus der Sachdatenanzeige heraus funktioniert nicht. Dies gilt sowohl für den Aufruf der Sachdaten über die Festpunktsuche bzw. aus der Karte heraus. Beim Klick auf 'Anzeige: in Karte' wird lediglich die Karte mit der letzten Ausdehnung angezeigt. Ein Zentrieren auf den gewünschten Punkt erfolgt leider nicht.
+Das Drücken des Button 'Festpunkte Anzeigen' zentriert auch nicht auf die recherchierten Punkte.
+:--[[Benutzer:HolgerR|HolgerR]] 17:14, 21. Apr 2008 (CEST) Nach Rücksprache mit Stefan hat sich herausgestellt, dass in unserer index.php zwischen case 'Sachdaten_Festpunkte Anzeigen' und case ' Festpunkte in Liste Anzeigen' folgender Eintrag fehlte:
+  case 'Festpunkte Anzeigen' : {
+    $GUI->festpunkteZeigen();
+  } break;
+== + Flächenmessung/Streckenmessung im IE ==
+Damit man den Kartenausschnitt nach einer Flächen- oder Streckenmessung auch im Internet Explorer verschieben kann, muss in der Datei SVG_map.php vor die
+beiden Zeilen
+ length = world_pathx.length;
+und
+ length = world_polypathx.length;
+jeweils ein '''var''' davorgesetzt werden, also so:
+ var length = world_pathx.length;
+und
+ var length = world_polypathx.length;
+== + Druckvorschau | Fehlermeldung ==
+--[[Benutzer:Hschmidt|Hschmidt]] 14:57, 17. Apr 2008 (CEST) <br>
+Beim Versuch die Druckvorschau aus der Druckausschnittswahl zu aktivieren kommt folgende Fehlermeldung:
+ Fatal error: Property 'width' does not exist in this object. in /usr/local/httpd-2.2.3/htdocs/kvwmap-1.6.8/class/kvwmap.php on line 8371
+--[[Benutzer:Hschmidt|Hschmidt]] 14:33, 17. Jul 2008 (CEST)<br>
+Die Fehlermeldung wurde durch einen fehlerhaften Style zu einem Layer verursacht. In der Spalte "width" des Styles war ein Wert eingetragen. Lässt man die Spalte leer tritt der Fehler nicht auf.
+Hat aber nichts mit der kvwmap-Version zu tun :-)
+== + Grundbuchblattsuche | Flurstücksdaten anzeigen  ==
+--[[Benutzer:Hschmidt|Hschmidt]] 14:09, 17. Apr 2008 (CEST) <br>
+Aus dem Ergebnis der Grundbuchblattsuche funktioniert das "Flurstücksdaten anzeigen" nicht.
+:--[[Benutzer:Rahn|Rahn]] 13:23, 18. Apr 2008 (CEST) Stimmt. Um den Fehler zu beheben, muss man im Snippet grundbuchblattanzeige.php die Zeile
+ <input name="go" type="hidden" value="">
+aus dem if-Block rausnehmen und darüber, hinter den anderen hidden-Feldern wieder einfügen.
+== + Stelle Wählen ==
+--[[Benutzer:Hschmidt|Hschmidt]] 12:54, 17. Apr 2008 (CEST)<br>
+Nach Auswahl der neuen Stelle und anschließendem betätigen des 'Start' - Buttons kommt die Meldung "Fehler beim Wechseln der Stelle. Prüfen Sie die Angaben.". Das Wechseln der Stelle funktioniert dann erst beim '''dritten Versuch''' die Stelle zu wechseln mit dem 'Start' - Button.<br>
+Das Einstellen einer anderen "Kartenprojektion (EPSG-Code)" funktioniert auch nicht.
+:--[[Benutzer:Rahn|Rahn]] 12:05, 18. Apr 2008 (CEST) Kann es sein, dass [[Bug_kvwmap#.2B_Stellenauswahl|hier]] dran liegt?
+::--[[Benutzer:Hschmidt|Hschmidt]] 07:32, 21. Apr 2008 (CEST) Nee, diese Einstellungen sind o.K.. Unter Version 1.6.7 läuft es ja auch problemlos.
+:::--[[Benutzer:Rahn|Rahn]] 15:23, 21. Apr 2008 (CEST) Das Problem bei Herrn Schmidt war, dass die Kartenausdehnung der neuen Stelle (z.B. 4501025 6001653,4502834 6003462) nicht korrekt angezeigt wurde. Hier fehlte immer das erste Leerzeichen. Hat vielleicht noch jemand dasselbe Problem?
+:::--[[Benutzer:HolgerR|HolgerR]] 16:51, 21. Apr 2008 (CEST) Jaha, bei uns tritt der Fehler auch auf. [[Log-Datei]]
+:::--[[Benutzer:HolgerR|HolgerR]] 11:27, 30. Apr 2008 (CEST) Problem ist bei uns mit diesen Einstellungen [[Bug_kvwmap#.2B_Stellenauswahl|'''hier''']] gelöst.
+== + Druckausschnitt wählen - Zoom ==
+--[[Benutzer:HolgerR|HolgerR]] 10:46, 17. Apr 2008 (CEST) Die Button 'Hereinzoomen' und 'Herauszoomen' beim Wählen und Plazieren des Druckrahmens vergrößern bzw. verkleinern nicht den Kartenausschnitt. Es wird lediglich der Kartenausschnitt neu zentriert. In der Stellenauswahl ist im Feld 'Zoomfaktor' eine 2 eingetragen.
+:--[[Benutzer:Rahn|Rahn]] 15:20, 21. Apr 2008 (CEST) Um den Fehler zu beheben, müssen folgende Funktionen im Snippet SVG_Druckausschnittswahl.php vor der Funktion focus_NAV() hinzugefügt werden:
+ <nowiki>
+ function zoomin(){
+   doing = "zoomin";
+   document.getElementById("canvas").setAttribute("cursor", "crosshair");
+ }
+ function zoomout(){
+   doing = "zoomout";
+   document.getElementById("canvas").setAttribute("cursor", "crosshair");
+ }
+ function zoomall(){
+   document.getElementById("canvas").setAttribute("cursor", "wait");
+   Full_Extent();
+ }
+ function recentre(){
+   doing = "recentre";
+   document.getElementById("canvas").setAttribute("cursor", "move");
+ }
+ function highlightbyid(id){
+   document.getElementById("zoomin0").style.setProperty("fill","ghostwhite", "");
+   document.getElementById("zoomout0").style.setProperty("fill","ghostwhite", "");
+   document.getElementById("recentre0").style.setProperty("fill","ghostwhite", "");
+   document.getElementById(id).style.setProperty("fill",highlighted, "");
+ }
+ </nowiki>
+== - Referenzkarte im Druck bei Nicht-Standard-SRS ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 09:09, 17. Apr 2008 (CEST) Wenn ich ein anderes als das für die Stelle als Standard definierte Koordinatensystem auswähle und anschließend die Karte drucke, bekomme ich kein oder ein falsch gelagertes Bild in der Referenzkarte - dort soll eine topographische Karte angezeigt werden, die als WMS eingebunden wird. Im entsprechenden Refmapfile steht in der connection nämlich die SRS drin und die verändert sich nicht, wenn der User das Koordinatensystem der Stelle wechselt.
+== + Kartenbild anzeigen ==
+Bei einigen scheint der Link "Kartenbild anzeigen" nicht zu funktionieren. Dazu die folgende Funktion in kvwmap.php austauschen:
+ <nowiki>
+ function showMapImage(){
+   $this->loadMap('DataBase');
+   $this->drawMap();
+   $dateiname = explode('.', basename($this->img['hauptkarte']));
+   if($dateiname[1] == 'jpg'){
+     $mainimage = imagecreatefromjpeg(IMAGEPATH.basename($this->img['hauptkarte']));
+     $scaleimage = imagecreatefromjpeg(IMAGEPATH.basename($this->img['scalebar']));
+   }
+   elseif($dateiname[1] == 'png'){
+     $mainimage = imagecreatefrompng(IMAGEPATH.basename($this->img['hauptkarte']));
+     $scaleimage = imagecreatefrompng(IMAGEPATH.basename($this->img['scalebar']));
+   }
+   ImageCopy($mainimage, $scaleimage, imagesx($mainimage)-imagesx($scaleimage), imagesy($mainimage)-imagesy($scaleimage), 0, 0, imagesx($scaleimage), imagesy($scaleimage));
+   ob_end_clean();
+   ob_start("output_handler");
+   ImagePNG($mainimage);
+ }
+ </nowiki>
+== - ALB-Einlesen - keine Auswertung der Kopfzeile ==
+--[[Benutzer:HolgerR|HolgerR]] 07:45, 16. Apr 2008 (CEST) Beim Einlesen der WLDGe-Bezieherdaten wird die Kopfzeile nicht ausgewertet, egal, ob das Auswahlfeld deaktiviert od. aktiviert ist. Damit ist das mehrmalige Einlesen der selben WLDGe-Datei bzw. das Auslassen von WLDGe-Dateien möglich.
+== + Zuweisen von Untermenüpunkten im InternetExplorer ==
+Im Stelleneditor werden bei Benutzung des IE die Untermenüpunkte nicht angezeigt. Um die Funktion auch in diesem "Browser" nutzen zu können, muss folgendes im Snippet stelle_formular.php getan werden:
+In der Funktion getsubmenues() muss die Zeile
+ ahah('<? echo URL.APPLVERSION; ?>index.php', 'go=getsubmenues&menue_id='+menue_id, new Array(document.GUI.submenues));
+durch diese hier ersetzt werden:
+ ahah('<? echo URL.APPLVERSION; ?>index.php', 'go=getsubmenues&menue_id='+menue_id, new Array(document.getElementById('submenue_div')));
+Außerdem müssen die Zeilen
+ <select name="submenues" size="4" multiple style="width:160px">
+ </select>
+durch diese hier ersetzt werden:
+ <nowiki>
+ <div id="submenue_div">
+   <select name="submenues" size="4" multiple style="width:160px">
+   </select>
+ </div>
+ </nowiki>
+Und dann muss in der Datei kvwmap.php folgende Funktion ersetzt werden:
+ <nowiki>
+ function get_sub_menues(){
+    $this->Menue = new menue($this->user->rolle->language,$this->user->rolle->charset);
+    $submenues = $this->Menue->getsubmenues($this->formvars['menue_id']);
+    echo '<select name="submenues" size="4" multiple style="width:160px">';
+    for($i=0; $i < count($submenues["Bezeichnung"]); $i++){
+      echo '<option selected value="'.$submenues["ID"][$i].'">&nbsp;&nbsp;-->&nbsp;'.$submenues["Bezeichnung"][$i].'</option>';
+    }
+    echo '</select>';
+  }
+ </nowiki>
+== + Löschen von Stellen ==
+Das Löschen von Stellen funktioniert nicht, weil der entsprechende Link in der Datei snippets/stellendaten.php nicht korrekt ist.
+Dazu in der Zeile
+ <nowiki><td>&nbsp;&nbsp;<a href="javascript:Bestaetigung('index.php?go=Stelle_Loeschen&selected_stelle_id=<? echo $this->stellendaten['ID'][$i]; ?>&order=<? echo $this->formvars['order']; ?>','Wollen Sie diese Stelle wirklich löschen?')"><?php echo $this->strDelete; ?></a></td></nowiki>
+das '''go=Stelle_Loeschen'''
+in '''go=Stelle_Löschen''' ändern.
+== + Beim Speichern neuer Stellen passiert auch nichts ==
+Das Problem ist das gleiche wie beim Anlegen von Layern (siehe nächster Bug). Hier muß die Datei stelle_formular.php angepasst werden.
+== + Beim Speichern neuer Layer passiert nichts ==
+--[[Benutzer:Pkorduan|Pkorduan]] 10:54, 28. Mär 2008 (CET) Wenn man einen Layer anlegt und dann als neuen Layer abspeichern möchte, ohne dass man vorher einen existierenden Layer ausgewählt hatte zum Ändern und speichern, passiert nichts.
+Das Problem kommt auch durch die Umstellung auf Multilingualität. Das Hidden Formularfeld für go_plus ist innerhalb des if Blocks, der ausgeführt wird, wenn man einen vorhandenen Layer als neuen abspeichern möchte.
+Fehlerbehebung:
+In Datei Layer_Formular.php im Verzeichnis Snippets die Zeile:
+ <input type="hidden" name="go_plus" id="go_plus" value="">
+vor die darüber stehende if Anweisung verschieben. Am besten direkt vor das Inputfeld
+ <input type="reset" value="<?php echo $this->strButtonBack; ?>">
+== + Fehler bei der Grundbuchblattanzeige von der Namenssuche aus ==
+--[[Benutzer:A.tower|Andreas Thurm]] 15:51, 20. Mär 2008 (CET)In der Ergebnisliste der Namenssuche kann man über einen Link zur Anzeige des Grundbuchblattes gelangen. Das funktioniert aber nicht in jedem Fall. Oftmals zeigt er ein ganz anderes Grundbuch an, oder bringt einen Fehler, das es das gesuchte Grundbuch nicht gibt. In wenigen Fällen zeigt er auch das richtige Grundbuch an. Ich konnte noch kein System erkennen. Es gibt in der Ergebnisliste ja auch noch den Link zum Anzeigen der Flurstücke. Hier werden die richtigen Flurstücke (vom gewählten Grundbuch) angezeigt. Allerdings werden standardmäßig nur maximal 10 Flurstücke angezeigt. Das ist gekoppelt an die Anzeige der Treffer pro Seite. Ist das so gewollt?
+--[[Benutzer:Rahn|Rahn]] 15:59, 15. Apr 2008 (CEST)
+Zum Beheben des Fehlers im Snippet namensuchform.php die beiden Zeilen
+ <nowiki>
+ <td align="center"><a href="javascript:grundbuchsuche(<?php echo $this->namen[$i]['bezirk'].','.$this->namen[$i]['blatt']; ?>);"><?php echo $this->namen[$i]['bezirk']; ?></a></td>
+ <td align="center"><a href="javascript:grundbuchsuche(<?php echo $this->namen[$i]['bezirk'].','.$this->namen[$i]['blatt']; ?>);"><?php echo $this->namen[$i]['blatt']; ?></a></td>
+ </nowiki>
+durch diese hier ersetzen:
+ <nowiki>
+ <td align="center"><a href="javascript:grundbuchsuche(<?php echo '\''.$this->namen[$i]['bezirk'].'\',\''.$this->namen[$i]['blatt'].'\''; ?>);"><?php echo $this->namen[$i]['bezirk']; ?></a></td>
+ <td align="center"><a href="javascript:grundbuchsuche(<?php echo '\''.$this->namen[$i]['bezirk'].'\',\''.$this->namen[$i]['blatt'].'\''; ?>);"><?php echo $this->namen[$i]['blatt']; ?></a></td>
+ </nowiki>
+== + Benutzer anlegen und bearbeiten ==
+In den Nutzereditor haben sich 2 kleine Fehler eingeschlichen, die aber dazu führen, dass man keinen neuen Benutzer mehr anlegen und vorhandene nicht bearbeiten kann. Um die Fehler zu beheben, muss im Snippet userdaten_formular.php die Zeile
+ <input type="button" name="dummy" value="<?php echo $this->strSave; ?>" onclick="submitWithValue('GUI','go_plus','aendern')"><?php
+durch diese hier ersetzt werden:
+ <input type="button" name="dummy" value="<?php echo $this->strSave; ?>" onclick="submitWithValue('GUI','go_plus','Ändern')">&nbsp;<?php
+und diese Zeile
+ ?><input type="button" name="dummy" value="<?php echo $strButtonSaveAs; ?>" onclick="submitWithValue('GUI','go_plus','neu_eintragen')">
+durch diese hier ersetzt werden:
+ ?><input type="button" name="dummy" value="<?php echo $strButtonSaveAs; ?>" onclick="submitWithValue('GUI','go_plus','Als neuen Nutzer eintragen')">
+= Version 1.6.7 =
+== + postgis_install.sql - fp_punkte2 - gist==
+--[[Benutzer:HolgerR|HolgerR]] 12:53, 11. Mär 2008 (CET)
+Im SQL-Statement hat sich ein kleiner Fehler eingeschlichen. Das Statement zur Erzeugung des Geo-Index muss wie folgt heissen:
+ CREATE INDEX fp_punkte2_the_geom_gist ON fp_punkte2 USING GIST (the_geom GIST_GEOMETRY_OPS);
+== - Anzeige der Flurstücke bei der Namenssuche ==
+--[[Benutzer:A.tower|Andreas Thurm]] 11:13, 26. Feb 2008 (CET)
+In der Ergebnisliste der Namenssuche werden die einzelnen gefundenen Grundbuchblätter aufgelistet. Der Link "anzeigen" in der Spalte Flurstücke suggeriert, das hier die Flurstücke des betreffenden Grundbuches angezeigt werden. Es werden hier aber alle Flurstücke für den betreffenden Eigentümer angezeigt (Funktion: Suche_flurstueck_zu _namen mit übergebener Namensnummer). Es erfogt keine Beschränkung auf das Grundbuchblatt. Das führt an dieser Stelle zu Missverständnissen. Wenn der Haken "Flurstücke anzeigen" gesetzt ist, bekommt man ebenfalls eine fehlerhafte Auflistung.
+*--[[Benutzer:Rahn|Rahn]] 11:37, 11. Mär 2008 (CET) Das stimmt, theoretisch müßte der Link "anzeigen" eigentlich nur die Flurstücke des jeweiligen Grundbuchsblattes anzeigen. Ich kann mich aber erinnern, dass damals eine Funktion gewünscht war, die alle Flurstücke zu einem Namen liefert, deshalb wurde sie so implementiert. Vielleicht sollten wir nochmal diskutieren, was der Link nun bewirken soll. Wie gesagt, rein logisch betrachtet, dürften nur die Flurstücke des jweiligen Grundbuchblattes angezeigt werden.
+== + Gemarkungsauswahl bei der Namenssuche ==
+--[[Benutzer:A.tower|Andreas Thurm]] 09:42, 26. Feb 2008 (CET)
+Wenn man in der Namenssuche keine Gemarkung angibt, so wird die Suche auch dementsprechend gestartet. Man erhält die ersten 10 Treffer. Will man dann weiter suchen, so ist das Eingabefeld mit der Gemarkung nicht mehr leer. Es steht die alphabetisch letzte Gemarkung drin. Und das wird auch bei der Weiter-Suche so berücksichtigt. Will am nalso blättern, so muss man jedesmal dieses Feld korrigieren und es wieder auf "-Auswahl-" stellen.
+== - Bugs in der Nachweiserfassung ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 12:31, 20. Feb 2008 (CET)<br>
+* Arbeiten zwei User in der Nachweiserfassung und ändern beide in derselben Sekunde das Kartenbild, überschreibt der eine das Bild des anderen. --[[Benutzer:Rahn|Rahn]] 14:22, 20. Feb 2008 (CET) '''behoben'''
+* Ab und zu wird kein (blau gefülltes) Polygon am Bildschirm erzeugt, sondern es erscheint nur der rote Rahmen. Das lässt sich speichern, allerdings wird die Bild-Datei mit 0 KB gespeichert. Ursache unbekannt.
+* Bei kombiniertem Zoomen/Pannen während des Zeichnens geht das Polygon verloren.
+* Ab und zu kommt eine XML-Fehlermeldung anstelle der Karte. Ursache unbekannt. [[Bild:xml-fehler_nachweiserfassung.png]]
+* Wenn es einen Fehler beim Speichern gab, wird immer die Bild-Datei mit 0 KB auf dem Server gespeichert. Es müsste nichts gespeichert werden.
+== + Lagebezeichnung im ALB-Ausdruck ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:31, 14. Feb 2008 (CET)<br>
+* Hat die Lagebezeichnung eines Flurstücks im ALB mehrere Hausnummern, weden diese momentan alphanumerisch und nicht numerisch sortiert: aus "1, 2, 3, 10" wird "1, 10, 2, 3". Die Hausnummern sollten aber numerisch sortiert bleiben.
+* Gibt es sehr viele Hausnummern, wird momentan über den Rand des Dokuments hinaus geschrieben, d.h. man kann den Rest der Hausnummern nicht mehr lesen. Hier müssten Zeilenumbrüche erfolgen, wobei die jeweils nächste Zeile linksbündig dort anfangen müsste, wo in der ersten Zeile der Lagebezeichnung der Straßenname anfängt (nicht der Straßenschlüssel!).
+== + Time-Attribut bei Geometrieänderung ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:16, 14. Feb 2008 (CET)
+Time-Attributfelder müssen auch dann aktualisiert werden, wenn etwas an der Geometrie eines Objektes geändert wird.
+== + Festpunktverwaltung - Feldlänge 'tex' == --[[Benutzer:HolgerR|HolgerR]] 14:02, 13. Feb 2008 (CET)
+Die Feldlänge in den Tabellen 'fp_punkte' und 'fp_punkte_temp' für die Abspeicherung des Datenelementes 'Text der Bemerkung' (TEX) ist nur 15 Zeichen lang. Laut Punktdateierlass M-V sind jedoch 18 Zeichen zulässig. Abhilfe schaffen hier folgende beiden SQL-Anweisungen:
+ ALTER TABLE fp_punkte_temp ALTER tex TYPE character varying(18);
+ ALTER TABLE fp_punkte ALTER tex TYPE character varying(18);
+== + Flächenanzeige im Polygoneditor ==
+Wenn man im Polygoneditor das Werkzeug zum Verschieben der Eckpunkte benutzt, wird die Flächenangabe nicht aktualisiert. Damit sie das tut, muss in SVG_Utilities.php in der Funktion end_vertex_move() am Ende des if-Blocks die Zeile
+ polygonarea();
+eingefügt werden.
+== + Platzhalter in der Namenssuche ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 09:09, 1. Feb 2008 (CET) In der Namenssuche steht ein gelb umrandeter Text, den vermutlich noch nie einer genauer durchgelesen hat, obwohl er von Anfang an nicht richtig war. Dort steht:
+"Zur nicht exakten Suche geben Sie den Platzhalter % ein.
+z.B. erhalten Sie Angermeier und Neumeier mit der Eingabe %meier"
+Das stimmt nicht, denn Angermeier und Neumeier erhält man auch durch die einfache Eingabe von meier. Mein Vorschlag:
+"Geben Sie den Platzhalter '''"%"''' ein (z.B. "me%er"), wenn an der Stelle beliebige und beliebig viele Zeichen stehen dürfen. Geben Sie den Platzhalter '''"_"''' ein (z.B. "me_er"), wenn an der Stelle ein beliebiges Zeichen stehen darf."
+Das Ganze vielleicht auch als Tooltipp hinter einem Info-Symbol, wie beim letzten Anwendertreffen besprochen.
+== + weitere Treffer anzeigen nach CSV-Export ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 09:45, 25. Jan 2008 (CET) Wenn man im GLE eine Trefferliste hat mit mehr Treffern, als MAXQUERYROWS erlaubt, dann kann man blättern. Wenn man einen CSV-Export durchführt, lässt sich jedoch nicht mehr blättern. Der Klick auf "weiter" öffnet nur wieder die CSV-Datei.
+== + Fehler beim Anzeigen von ALB-Auszügen für '''alle''' Flurstücke ==
+--[[Benutzer:Giese|FrankGiese]] 11:12, 21. Jan 2008 (CET)
+* Bei einigen Nutzern (nicht bei allen Nutzern), die mit dem Microsoft Internet Explorer arbeiten und sich ALB-Auszüge (20,25,30,35) für '''alle''' ausgewählte Flurstücke aufrufen, öffnet sich ein neues Fenster (Acrobat Reader) und der Auszug wird in der Größe von 213% dargestellt. Es gibt keine Möglichkeit die Fenstergröße anzupassen, weil die Schaltfläche minimieren deaktiviert ist. Setzt man den Maßstab herab hat man nur den Erfolg, dass der Ausschnitt verkleinert dargestellt wird. Die Ausdehnung des Fensters bleibt aber gleich. In der Version 1.6.6 gab es dieses Problem nicht. Auch beim Aufruf der ALB-Anzeige für nur ein Flurstück funktioniert es in der Version 1.6.7 tadellos.
+**--[[Benutzer:Markus Hentschel|Markus Hentschel]] 11:51, 21. Jan 2008 (CET) Diesen Unterschied habe ich auch. Irgendwelche fehlenden/falschen Dateiheader? Die "Start"-Vergrößerung des Dokuments kann man jedoch beeinflussen, indem man (beim Acrobat Reader 7) auf "''Bearbeiten''" - "''Grundeinstellungen''..." geht und dort bei ''Seitenanzeige'' die sog. '''Standardvergrößerung''' verändert - z.B. auf '''Fenstergröße'''. Das muss allerdings auf jedem Rechner einzeln gemacht werden.
+***--[[Benutzer:Giese|FrankGiese]] 12:42, 21. Jan 2008 (CET) Danke Markus, aber das führte bei uns leider nicht zum Erfolg.
+****--[[Benutzer:Rahn|Rahn]] 13:56, 1. Feb 2008 (CET) Versucht mal in der Flurstuecke_custom.php in folgender Zeile die Breite und Höhe runter zu setzen, also z.B. auf width=1024,height=768
+ window.open(url, "CSVExport", "toolbar=yes,status=yes,menubar=yes,width=2000,height=2000");
+::::*--[[Benutzer:Markus Hentschel|Markus Hentschel]] 07:05, 4. Feb 2008 (CET) Gibts nicht sowas wie screen.availWidth und screen.availHeight?
+:::::*--[[Benutzer:Rahn|Rahn]] 14:51, 4. Feb 2008 (CET) Gibts! :
+ window.open(url, "CSVExport", "toolbar=yes,status=yes,menubar=yes,width="+self.screen.width+",height="+self.screen.height);
+== + Fehler in der Nachweisrecherche und im Punkteditor ==
+Durch die neue Funktion zum Bearbeiten von Polygonpunkten tritt im Nachweisrechercheformular und im Punkteditor ein Fehler auf. Um den Fehler zu beheben, muss in den Dateien SVG_polygon_box_area.php und SVG_point.php folgende Zeile
+ <input name="vertex_edit" type="hidden" value="<?php echo $this->formvars['vertex_edit']; ?>">
+an den Abschnitt mit den ganzen input-Feldern angehängt werden.
+In SVG_polygon_box_area.php muss nach der Zeile
+ $svg .= $boxbuttons;
+außerdem noch die Zeile
+ $svg .= $vertex_edit_buittons;
+angehängt werden.
+Analog zur Datei SVG_polygon_box_area.php müssen auch die Dateien SVG_polygon_xor_point.php und SVG_polygon_and_point.php angepasst werden.
+== - Namenssuche | Suchen mit Entertaste ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 14:46, 14. Jan 2008 (CET)
+Wenn man in der Namenssuche ist und z.B. einen Namen eingegeben hat, dann kann man nicht mit [Enter] die Suche starten. Die Entertaste bringt einen vielmehr wieder zur Karte zurück. Ist das gewollt oder ein Bug?
+== + Adressänderungstabelle bereinigen ==
+Bei einigen PostgreSQL-Versionen kann es zu Problemen kommen, wenn man versucht die Tabelle alb_g_namen_temp zu bereinigen.
+Um den Fehler zu beheben, muss folgende Funktion in esaf.php ausgetauscht werden:
+ <nowiki>function delete_old_entries(){
+   $sql = "DELETE FROM alb_g_namen_temp ";
+   if(POSTGRESVERSION >= '810'){
+     $sql.=" USING alb_g_namen ";
+   }
+   $sql.= "WHERE ((alb_g_namen_temp.name1 IS NULL AND (alb_g_namen.name1 IS NULL OR alb_g_namen.name1 = '')) OR alb_g_namen_temp.name1 = alb_g_namen.name1)";
+   $sql.= "AND ((alb_g_namen_temp.name2 IS NULL AND (alb_g_namen.name2 IS NULL OR alb_g_namen.name2 = '')) OR alb_g_namen_temp.name2 = alb_g_namen.name2)";
+   $sql.= "AND ((alb_g_namen_temp.neu_name3 IS NULL AND (alb_g_namen.name3 IS NULL OR alb_g_namen.name3 = '')) OR alb_g_namen_temp.neu_name3 = alb_g_namen.name3)";
+   $sql.= "AND ((alb_g_namen_temp.neu_name4 IS NULL AND (alb_g_namen.name4 IS NULL OR alb_g_namen.name4 = '')) OR alb_g_namen_temp.neu_name4 = alb_g_namen.name4)";
+   $ret = $this->database->execSQL($sql, 4, 0);
+ }</nowiki>
+= Version 1.6.6 =
+== - Fehler in Notizkategorienverwaltung ==
+--[[Benutzer:Hschmidt|Hschmidt]] 15:36, 8. Jan 2008 (CET)<br>
+Notizen können in allen Stellen gelesen werden, obwohl in der Notizkategorienverwaltung das Recht "lesen" für die Notiz-Kategorie nicht gesetzt ist.
+== + Feld Wert in der Filterverwaltung muss Typ 'text' sein ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 11:38, 14. Dez 2007 (CET) Filterausdrücke können durchaus länger als 255 Zeichen sein. Deswegen müssen die Eingabefelder des Werts in der Filterverwaltung beliebig lange Einträge zulassen.
+== + als neuer Druckrahmen speichern | Ref.-Mapfile ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 15:07, 5. Dez 2007 (CET) Wenn man von einem vorhandenen Druckrahmen als neuen Druckrahmen speichert, wird der Eintrag zum Referenzkartenmapfile nicht kopiert.
+== + OID in Hochkomma ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 11:33, 3. Dez 2007 (CET)<br>
+In ''polygoneditor.php'' muss die vierte Zeile der function zoomTopolygon() geändert werden:
+  function zoomTopolygon($oid, $tablename, $border) {
+    ...
+    $sql.= " FROM ".$tablename." WHERE oid = '".$oid."';";
+    ...
+In kvwmap.php muss in der function sachdaten_speichern() die Zeile mit "WHERE oid =" geändert werden:
+ ...
+ if($attributname != 'oid'){
+   if($this->formvars[$form_fields[$i]] == ''){
+      $sql = "UPDATE ".$tablename." SET ".$attributname." = NULL WHERE oid = '".$oid."';";
+   }
+   else{
+      $sql = "UPDATE ".$tablename." SET ".$attributname." = '".$this->formvars[$form_fields[$i]]."' WHERE oid = '".$oid."';";
+ ...
+== + Nachweiserfassung/-recherche | Länge von Stammnummer und Blattnummer ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 09:38, 3. Dez 2007 (CET)<br>
+In der Nachweisdokumenteingabe muss die Zeichenlänge der Blattnummer variabel sein. Dazu muss in der config.php ein neuer Parameter hinzukommen:
+ # Erlaubte maximale Länge der Blattnummer in der Fachschale Nachweisverwaltung
+ define('BLATTNUMMERMAXLENGTH',4);
+In der Datei dokumenteneingabeformular.php muss es dann entsprechend heißen:
+ <nowiki><td colspan="2">Blattnummer:
+  <input name="Blattnr" type="text" value="<?php echo $this->formvars['Blattnr']; ?>" size="<?php echo BLATTNUMMERMAXLENGTH; ?>" maxlength="<?php echo BLATTNUMMERMAXLENGTH; ?>">
+ </td></nowiki>
+In der Nachweisdokumentsuche fehlt die Variable STAMMNUMMERMAXLENGTH. In der Datei dokumentenabfrageformular.php muss es richtig heißen:
+ <nowiki><td colspan="2">          Stammnummer<br>
+  <input type="text" name="suchstammnr" value="<?php echo $this->formvars['suchstammnr']; ?>" size="<?php echo STAMMNUMMERMAXLENGTH; ?>" maxlength="<?php echo STAMMNUMMERMAXLENGTH; ?>">
+ </td></nowiki>
+In der Datenbank ist in der Tabelle n_nachweise das Attribut ''stammnr'' varchar(8). Es sollte vielleicht - genau wie das Attribut ''blattnummer'' - nur varchar sein.
+:--[[Benutzer:Markus Hentschel|Markus Hentschel]] 10:51, 6. Dez 2007 (CET) In der Datei nachweisanzeige.php muss die Variable BLATTNUMMERMAXLENGTH ebenfalls eingetragen werden:
+ <nowiki><td><div align="center"><?php echo $this->formvars['blattnummer']=str_pad(intval($this->nachweis->Dokumente[$i]['blattnummer']),BLATTNUMMERMAXLENGTH,'0',STR_PAD_LEFT); ?></div></td></nowiki>
+== - Gemarkungsauswahl in der Namenssuche ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 12:48, 26. Okt 2007 (CEST)<br>
+Wenn man in der Namenssuche eine Recherche durchgeführt hat, wird anschließend die letzte der auswählbaren Gemarkungen im Feld "Gemarkung(Gemeinde)" angezeigt. Das ist bei verschiedenen Stellen der Fall, wobei ich kein Muster erkennen kann. Bin ratlos.
+== + Notizen | Fehlermeldung Notizenformular ==
+--[[Benutzer:Hschmidt|Hschmidt]] 11:42, 24. Okt 2007 (CEST)<br>
+Wenn man im Notizenformular die Kategorien bearbeiten will und man über die Stelle nicht das Recht der Funktion  "kategorienverwaltung" hat kommt die Fehlermeldung
+ Fatal error: Cannot access empty property in /usr/local/httpd-2.2.3/htdocs/kvwmap-1.6.6/index.php on line 672
+Dieses sollte durch die übliche Meldung dass man nicht das entsprechende Recht besitzt abgefangen werden.
+== - Stellenverwaltung | Stelle kopieren ==
+--[[Benutzer:Hschmidt|Hschmidt]] 11:32, 16. Okt 2007 (CEST)<br>
+Beim Kopieren einer Stelle über die Stellenverwaltung mit "Als neue Stelle eintragen" werden die Layer-Werte für "transparency" nicht mit übernommen, was sinnvoll wäre.
+== + Shape-Export ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 14:52, 15. Okt 2007 (CEST) Beim Auswählen einiger Layer im Shape-Export kommt eine Fehlermeldung, die ein zertrümmertes SQL anmeckert. Warum nur bei einigen, weiß ich nicht.
+Der Fehler tritt bei den Layern auf, die keine Where-Klausel im Data-Statement haben. Zum Beheben also entweder ''where 1=1'' hinten ran hängen oder in postgresql.php in der Funktion eliminate_star() den else-Zweig:
+ else{
+    $whereposition = strpos(strtolower($query), 'where');
+    $withoutwhere = substr($query, 0, $whereposition);
+    $fromposition = strpos(strtolower($withoutwhere), 'from');
+   }
+durch den hier ersetzen:
+ else{
+    $whereposition = strpos(strtolower($query), 'where');
+    if($whereposition){
+     $withoutwhere = substr($query, 0, $whereposition);
+    }
+    else{
+     $withoutwhere = $query;
+    }
+    $fromposition = strpos(strtolower($withoutwhere), 'from');
+   }
+== - Generischer Layereditor (GLE) ==
+--[[Benutzer:Hschmidt|Hschmidt]] 08:38, 7. Dez 2007 (CET)<br>
+Nachträgliches Erfassen von Geometrien unmöglich.<br>
+Wenn man im Layereditor einen Datenbestand bearbeiten will, den man z.B. von einer csv-Datei eingelesen hat und der noch keine Geometrie enthält, ist das nachträgliche Erfassen der Geometrie (Polygon) nicht möglich, obwohl die Geometriespalte vorhanden ist und in der Rechteverwaltung die Geometrie auf "editieren" gestellt wurde.
+--[[Benutzer:Rahn|Rahn]] 11:35, 7. Dez 2007 (CET) Liegt das vielleicht daran, dass die Tabelle nicht in geometry_columns eingetragen ist? <br>
+--[[Benutzer:Hschmidt|Hschmidt]] 07:09, 11. Dez 2007 (CET)Stimmt, das wars! Beim Einlesen über eine CSV-Datei wird kein Eintrag in die geometry_colums gemacht. Das habe ich mit einem Insert nachgeholt:-)
+--[[Benutzer:Reißland|Reißland]] 14:08, 15. Okt 2007 (CEST)<br>
+folgende Kleinigkeiten sind mir beim Arbeiten mit dem GLE in 1.6.5 aufgefallen. Aus Zeitmangel habe ich nicht getestet ob alle in 1.6.6 schon behoben sind. Sollte das der Fall sein, bitte ich die Hinweise zu ignorieren.<br>
+* Enthalten Tabellen ein CONSTRAINT das ein Komma beinhaltet (RFW1,RFW2) wird dieses nicht ordnungsgemäß ins Auswahlfeld des GLE übernommen.
+* Besteht ein CONSTRAINT aus Zahlenwerten wird es im Attributeditor nicht automatisch als Auswahlfeld markiert.
+* Enthalten Tabellen Attribute mit Anführungszeichen (Wohngruppe "Sonnenschein") wird das Attribut im GLE vor dem Anführungszeichen abgeschnitten (Wohngruppe). Einfache Anführungszeichen funktionieren zwar, führen aber bei der Datenaktualisierung zu einer Fehlermeldung.
+* Ist eine Tabellenspalte mit einem NOT NULL CONTRAINT versehen, erscheint im GLE im Auswahlfeld trotz allem eine Leerzeile. Bei Auswahl dieser Leerzeile kommt beim Abspeichern zwar eine Fehlermeldung, besser wäre aber, wenn die Leerzeile gar nicht vorhanden wäre.
+--[[Benutzer:Rahn|Rahn]] 14:16, 26. Okt 2007 (CEST)
+<Fehler behoben>
+* Bei der Eingabe eines neuen Datensatzes (go=neuer_Layer_Datensatz) werden die bereits eingegebenen Attribute wieder gelöscht, wenn der Bearbeiter zur Geometrieeingabe im Kartenfenster zoomt.
+* --[[Benutzer:Markus Hentschel|Markus Hentschel]] 11:39, 25. Okt 2007 (CEST) Bei der Eingabe eines neuen Datensatzes (go=neuer_Layer_Datensatz) werden die bereits eingegebenen Attribute auch wieder gelöscht, wenn der Bearbeiter erst nach der Eingabe einen Geometrieabfragelayer auswählt. Der Bearbeiter müsste gezwungen werden, ERST alle notwendigen Einstellungen zu tätigen, BEVOR er Sachdaten eingibt.
+</Fehler behoben>
+== - Lagebezeichnung im ALB-Ausdruck ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 10:58, 15. Aug 2007 (CEST)<br>
+* Hat die Lagebezeichnung eines Flurstücks im ALB mehrere Hausnummern, weden diese momentan alphanumerisch und nicht numerisch sortiert: aus "1, 2, 3, 10" wird "1, 10, 2, 3". Die Hausnummern sollten aber numerisch sortiert bleiben.
+* Gibt es sehr viele Hausnummern, wird momentan über den Rand des Dokuments hinaus geschrieben, d.h. man kann den Rest der Hausnummern nicht mehr lesen. Hier müssten Zeilenumbrüche erfolgen, wobei die jeweils nächste Zeile linksbündig dort anfangen müsste, wo in der ersten Zeile der Lagebezeichnung der Straßenname anfängt (nicht der Straßenschlüssel!).
+== + Layernamen mit Sonderzeichen im Shape-Export ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 12:36, 15. Okt 2007 (CEST) Bei Layernamen, die Sonderzeichen enthalten (z.B. Leerzeichen) kommt es zu Fehlern beim Herunterladen aus dem Shape-Export heraus. Die Sonderzeichen müssten im Layernamen aufgelöst werden, z.B. Unterstrich statt Leerzeichen.
+== + Anzeige der Namensnummern im ALB-Auszug 35 ==
+--[[Benutzer:A.tower|Andreas Thurm]] 13:01, 8. Okt 2007 (CEST) Im ALB-Auszug 35 werden die Namensnummern nur bis zur zweiten Stelle angezeigt obwohl sie in der Datenbank komplett gespeichert sind. Beispiel: In der Spalte namensnr der Tabelle alb_g_eigentuemer ist der Wert 2.01.01 gespeichert. Im ALB-Formular 35 steht dann nur 2.01.
+== + Nachweise mit alphanumerischer Blattnummer anzeigen ==
+Damit die Nachweise mit alphanumerischer Blattnummer nach einer Recherche korrekt angezeigt werden muß in nachweisanzeige.php die Zeile
+ <nowiki><td><div align="center"><?php echo $this->formvars['blattnummer']=str_pad(intval($this->nachweis->Dokumente[$i]['blattnummer']),3,'0',STR_PAD_LEFT); ?></div></td></nowiki>
+durch diese hier ersetzt werden:
+ <nowiki><td><div align="center"><?php echo $this->formvars['blattnummer']=str_pad($this->nachweis->Dokumente[$i]['blattnummer'],3,'0',STR_PAD_LEFT); ?></div></td></nowiki>
+== + Zuweisung von Festpunkten zu einem Antrag ==
+--[[Benutzer:A.tower|Andreas Thurm]] 10:17, 19. Sep 2007 (CEST)Seit dem ich in der php.ini die erforderlichen Änderungen betreffs des Übergangs zur Version 1.65 vorgenommen habe, kann ich keine Festpunkte mehr zu einem Antrag zuordnen. Ein Klick auf den dem entsprechenden Button führt zu keinem Ergebnis. Es wird die momentan aktuelle Seite wieder aufgebaut.
+== + Erzeugen eines Arbeitsdrucks (index.php?go=ExportMapToPDF)==
+--[[Benutzer:Reißland|Reißland]] 09:38, 17. Sep 2007 (CEST) Beim erstellen eines "Arbeitsdrucks" (go-Variable=ExportMapToPDF) erhält man nicht wie in vorherigen Versionen die Angaben Gemarkung, Flur, Flurstück sondern lediglich die Ausschrift "Array".
+== + Fehler in der Rechteverwaltung ==
+Wer eine MySQL-Version kleiner 4.10 hat, der bekommt beim Setzen der Layerattributrechte einen Fehler. Zum Beheben in der Funktion set_attributes_privileges in users.php in diesem Abschnitt:
+ if(MYSQLVERSION < 410){
+   $sql = 'REPLACE INTO layer_attributes2stelle SET ';
+   $sql.= 'layer_id = '.$layer_id.', ';
+   $sql.= 'stelle_id = '.$this->id.', ';
+   $sql.= 'attributename = "'.$attributename.'", ';
+   $sql.= 'privileg = '.$privileg.', ';
+   if($tooltip == 'on'){
+      $sql.= ', tooltip = 1';
+   }
+   else{
+      $sql.= ', tooltip = 0';
+   }
+   if($tooltip == 'on'){
+      $sql.= 'tooltip = 1';
+   }
+   else{
+      $sql.= 'tooltip = 0';
+   }
+   ...
+diese Zeilen entfernen:
+ if($tooltip == 'on'){
+   $sql.= ', tooltip = 1';
+ }
+ else{
+   $sql.= ', tooltip = 0';
+ }
+--[[Benutzer:Hschmidt|Hschmidt]] 10:20, 19. Sep 2007 (CEST)<br>
+== + Layerattribut-Rechteverwaltung ==
+Die Layerattribut-Rechteverwaltung ist selbst nicht geschützt und lässt sich in jeder Stelle über index.php?go=Layerattribut-Rechteverwaltung aufrufen. Besser wäre es wenn diese nur über die Adminstratorfunktionen aufzurufen wäre.
+== - maxsize bei den Attributen im GLE ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 12:30, 7. Sep 2007 (CEST)<br>
+Bei der Eingabe von Sachdaten im GLE kann man mehr Zeichen eingeben, als laut Definition in der Postgis zugelassen sind. Entsprechend gibts eine Fehlermeldung beim Speichern und das Speichern scheitert. Die Länge der Input-Felder muss auf die Attribut-Zeichenlänge laut DB-Definition begrenzt sein.
+== + Verschieben des Bildausschnittes beim Setzen eine Umrings ==
+--[[Benutzer:Karsten Daedelow]] 11:55, 7. Sep 2007 -- >
+Will man beim Setzen eines Umrings den Bildauschnitt schieben, verschwindet der Umring und man kann von vorn beginnen.
+:--[[Benutzer:Rahn|Rahn]] 14:22, 12. Sep 2007 (CEST) Um den Fehler zu beheben, in der SVG_Utilities.php die Zeile
+ if(top.document.GUI.newpath.value && polygonfunctions == true){
+durch diese hier ersetzen:
+ if(top.document.GUI.newpath.value){
+== - Maßstab der Karte nach Absenden von Geometrieänderungen ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 15:32, 5. Sep 2007 (CEST)<br>
+Ich bin mir nicht sicher, ob es gewollt oder ein Bug ist: Wenn man eine Geometrie bearbeitet hat und beim Bearbeiten in die Karte gezoomt hat, kommt man nach dem Senden wieder in den originalen Maßstab, den man vor dem Bearbeiten hatte. Das macht das Bearbeiten aber sehr mühselig, wenn man an einem Objekt mehrere Änderungen zu machen hat. Besser wäre, generell den jeweils letzten Maßstab zu behalten.
+== + Generischer Layereditor | Geometrieabfrage-Layer: Flurstuecke  ==
+--[[Benutzer:Hschmidt|Hschmidt]] 10:17, 5. Sep 2007 (CEST)<br>
+Bei der Auswahl des Flurstückslayers als Geometrieabfrage-Layer um z.B. Flurstücksgeometrien hinzuzufügen kommt im Fläche-Fensterchen folgende Fehlermeldung, die evtl. darauf hindeutet, dass keine Geometrie übergeben wird:
+ Warning:  pg_query() function.pg-query: Query failed: ERROR:  unterminated quoted string at or near &quot;'\'))::numeric, 2)
+ at character 32 in /usr/local/httpd-2.2.3/htdocs/kvwmap-1.6.6/class/postgresql.php on line 3809 Fehler bei SQL Anweisung:
+ SELECT round(Area(GeomFromText('\'))::numeric, 2)
+Das gleiche zeigt sich auch in der Log-Datei.
+Bei anderen PostGis-Layern wie z.B. Fluren funktioniert das Hinzufügen von Geometrien.
+:--[[Benutzer:Rahn|Rahn]] 09:20, 12. Sep 2007 (CEST) Das hängt damit zusammen, dass für den Flurstückslayer 2 Tabellen abgefragt werden, die beide eine Spalte the_geom haben. Nämlich alkobj_e_fla und alkobj_t_pkt. Für die Geometrieabfrage wird das Attribut verwendet, welches im Data-Statement an erster Stelle steht. Also the_geom. Es ist aber nicht klar, welches the_geom abgefragt werden soll und die Abfrage funktioniert nicht. Damit sie funktioniert, muß man die Unterabfrage so umbenennen wie die Tabelle alkobj_e_fla und diesen Bezeichner dann vor the_geom setzen. Also z.B. so:
+ o.the_geom from (select o.objnr as oid,o.objart,o.folie,o.the_geom,f.flurstkennz,f.gemkgschl,
+ t.label from alkobj_e_fla AS o,alknflst as f,alkobj_t_pkt AS t WHERE o.folie='001' AND o.objnr=f.objnr
+ AND o.objnr=t.objnr) as o using unique oid using srid=2398
+:--[[Benutzer:Hschmidt|Hschmidt]] 09:03, 19. Sep 2007 (CEST) <br>Prima jetzt klappt es:-) Nützlich wäre noch in den Install und Update-Scripten das Data-Statement des Flurstückslayers daraufhin zu ändern.
+== + PostGIS Update per SQL  ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 15:15, 4. Sep 2007 (CEST)<br>
+postgis_update.sql: In den CREATE TABLE Befehlen von den Tabellen ''anliegerbeitraege_bereiche'' und ''anliegerbeitraege_strassen'' ist jeweis der folgende Constraint zu viel und muss rausgelöscht werden:
+ CONSTRAINT enforce_dims_the_geom CHECK (ndims(the_geom) = 2)
+Dasselbe in der Datei postgis_install.sql
+== - config.php Kennzeichnung der Änderungen  ==
+--[[Benutzer:Hschmidt|Hschmidt]] 14:25, 4. Sep 2007 (CEST)
+* Leider sind in der config-default.php nicht alle Änderungen gekennzeichnet. Das macht die Aktualisierung etwas mühselig.
+* Der Eintrag "$Gazdb->dbName='gazetteers';	# Version 1.6.6" sollte auskommentiert werden, weil er sonst bei fehlender DB zu einer Fehlermeldung führt.
+= Version 1.6.5 =
+== + Layernamen mit Sonderzeichen in der Drucklegende ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 14:17, 15. Aug 2007 (CEST)<br>
+Beinhaltet ein Layername Sonderzeichen oder Leerzeichen, die als HTML-Characters geschrieben sind (Beispiel: "Geb&auml;ude" o.ä.), dann stehen diese HTML-Characters in der Legende. Sie müssten durch die richtigen Zeichen ersetzt werden.
+== - Lagebezeichnung im ALB-Ausdruck ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 10:58, 15. Aug 2007 (CEST)<br>
+* Hat die Lagebezeichnung eines Flurstücks im ALB mehrere Hausnummern, weden diese momentan alphanumerisch und nicht numerisch sortiert: aus "1, 2, 3, 10" wird "1, 10, 2, 3". Die Hausnummern sollten aber numerisch sortiert bleiben.
+* Gibt es sehr viele Hausnummern, wird momentan über den Rand des Dokuments hinaus geschrieben, d.h. man kann den Rest der Hausnummern nicht mehr lesen. Hier müssten Zeilenumbrüche erfolgen, wobei die jeweils nächste Zeile linksbündig dort anfangen müsste, wo in der ersten Zeile der Lagebezeichnung der Straßenname anfängt (nicht der Straßenschlüssel!).
+== + Stellenwechsel ==
+--[[Benutzer:Reißland|Reißland]] 10:13, 27. Jul 2007 (CEST)<br>
+#Beim Wechsel einer Stelle wird der Extent der Karte aus der aktuellen Stelle für die neue Stelle übernommen.
+#Bei der Auswahl einer Stelle erscheint ein IE-Error '''AHAH-Error 12029 Unknown'''. Liegt das an der Version des IE (bei mir 6.0.2900.2180)?
+:--[[Benutzer:Rahn|Rahn]] 15:39, 27. Jul 2007 (CEST) Guck mal weiter unten beim Bug "Stellenauswahl".
+== + Nachweisverwaltung - Nachweise löschen ==
+--[[Benutzer:HolgerR|HolgerR]] 16:01, 26. Jul 2007 (CEST)<br>
+Im Rechercheergebnis wird auch den berechtigten Stellen das Recht zum Löschen von Nachweisen nicht eingeräumt. Abhilfe schafft hier die Korrektur des Snippets 'nachweisanzeige.php'. Der Eintrag
+          	<? if($this->Stelle->isFunctionAllowed('Nachweiseloeschen')){ ?>
+in Zeile 127 muss richtig
+          	<? if($this->Stelle->isFunctionAllowed('Nachweisloeschen')){ ?>
+heißen. Im Funktionsname ist quasi ein 'e' zuviel.
+:--[[Benutzer:Rahn|Rahn]] 15:36, 27. Jul 2007 (CEST) Tja, das ist jetzt die Frage ob wir alle das Snippet ändern oder den Namen der Funktion in der Datenbank. Ich kann mich erinnern, dass die MST-Leute auch schon auf das Problem gestoßen waren und wir damals den Funktionsnamen in der Datenbank in "Nachweis'''e'''loeschen" geändert haben. Deswegen schlag ich vor, dass alle anderen das auch so machen.
+== - Sachdatenabfrage ==
+--[[Benutzer:HolgerR|HolgerR]] 08:35, 26. Jul 2007 (CEST)<br>
+Wird aus der Karte heraus eine Sachdatenabfrage mit dem Info-Button durchgeführt, erzeugen PostGIS-Kartenthemen, die keine OID-Spalte besitzen einen Fehlereintrag in der PostgreSQL-Logdatei.
+-07-25 11:32:01 CEST user datenbank [local] 23211 SELECT ERROR:  column "oid" does not exist
+-07-25 11:32:01 CEST user datenbank [local] 23211 SELECT STATEMENT:  SELECT oid from alknflst limit 1
+Dieser Fehler wird in der Funktion 'check_oid' in postgresql.php durch die fehlende OID-Spalte generiert. Das ist zwar nicht weiter schlimm, für die Übersichtlichkeit der Logdatei ist es aber doch nicht optimal. Abhilfe könnte m.E. folgende geänderte Funktion 'check_oid' schaffen:
+  function check_oid($tablename){
+    $sql = 'SELECT * FROM '.$tablename.' LIMIT 1';
+    @$query=pg_query($sql);
+    $anz_felder = pg_num_fields($query); # Anzahl der Felder in jeweiliger Tabelle
+    $j = 0;
+    $rueckgabe_wert = false;
+    while ($j <> $anz_felder AND $rueckgabe_wert = false) {
+      $feldname = pg_field_name($query, $j); # Herauslesen der Feldnamen
+      if ($feldname == 'oid') {
+        $rueckgabe_wert = true;
+      } # if
+    } # while
+    return $rueckgabe_wert;
+  } # function check_oid
+Vielleicht gibt es elegantere Lösungen. Es wäre jedoch auf alle Fälle gut, wenn wegen der Übersichtlichkeit in der PostgreSQL-Logdatei der Fehlereintrag in Zukunft verhindert wird.
+:--[[Benutzer:Rahn|Rahn]] 11:03, 26. Jul 2007 (CEST)<br>Mit SELECT * FROM <Tabelle> fragt man zwar alle Spalten der Tabelle ab, aber nicht die systeminterne Spalte oid, auch wenn sie vorhanden ist.
+== - menues2stelle bei Änderungen ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 07:34, 26. Jul 2007 (CEST)<br>
+Wenn man mit dem Stelleneditor Änderungen in einer Stelle vornimmt, werden beim Absenden ALLE Untermenüs eines Obermenüs an die Stelle und an alle User der Stelle gebunden. Das ist u.U. nicht gewollt. Die Jagdbezirkssuche oder die Bauauskunft sind z.B. normalerweise nicht in allen Stellen nötig.
+<br>
+--SigridP 12:51, 26. Jul 2007 (CEST)<br>
+Da im Stelleneditor die Menuepunkte nur als Obermenue (z.B. Suchen) zugeordnet werden können, werden bei Änderungen alle Menues mit der Menueebene 2 innerhalb eines Obermenues übernommen. Ich habe mir so geholfen, dass ich einige Menues, wie z.B. Bauauskunft und Jagdkataster ohne Obermenue mit der Menueebene 1 definiert habe.
+:--[[Benutzer:Markus Hentschel|Markus Hentschel]] 08:43, 13. Aug 2007 (CEST)<br>
+:Ja, an so was habe ich auch schon gedacht. Aber eigentlich ist es ja in Ordnung, wenn es ein Obermenü "Suche" gibt, in der '''alle''' Suchfunktionen vereinigt sind. Wenn dann nebenher noch einige Suchfunktionen in Menüebene 1 herumgeistern, ist es doch vielleicht für den Anwender ein bißchen irritierend, weil unlogisch. Eine grundsätzliche Lösung wäre meiner Meinung nach besser.
+== - Referenzkarte bei maximalem Extent im Druck ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 08:22, 25. Jul 2007 (CEST)<br>
+Wenn der Zoomfaktor der Referenzkarte im Druckrahmen > 1 ist und man den maximalen Extent (z.B. den ganzen Landkreis) drucken will, dann wird die Referenzkarte entsprechend auf den maximalen Extent gesetzt, sondern hat den halben maximalen Extent der Karte (halb = vermutlich Zoomfaktor?). Den EXTENT im refmapfile.map zu vergrößern, bringt nichts.
+== + Trefferliste Namenssuche ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:05, 11. Jul 2007 (CEST)<br>
+Nicht direkt ein Fehler, aber wegen Geringfügigkeit auch kein Entwicklungswunsch: Es wäre besser, wenn in der Trefferliste der Namenssuche die Attribute "Geburtsdatum/Zusatz", "Name/Firma", "Straße HausNr" und "PLZ Ort" eine linksbündige Ausrichtung hätten.
+== + logconsume in Stelle anlegen ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 10:38, 10. Jul 2007 (CEST)<br>
+Beim Anlegen einer Stelle kann ich den logconsume nicht auswählen, entsprechend kommt nach dem Speichern eine Fehlermeldung.
+:--[[Benutzer:Rahn|Rahn]] 11:06, 13. Jul 2007 (CEST) Die Fehlermeldung kann eigentlich nur kommen, wenn die Spalte logconsume auf NOT NULL gesetzt ist.
+::--[[Benutzer:Markus Hentschel|Markus Hentschel]] 11:59, 17. Jul 2007 (CEST) Die Spalte logconsume ist aber auf NULL gesetzt!?
+== + SHP-Import==
+Beim Shp-Import hat sich noch ein Bug eingeschlichen. Zum Beheben des Fehlers in kvwmap.php in der Funktion shp_import_speichern die Zeile
+ exec(POSTGRESBINPATH.'psql -f '.IMAGEPATH.$this->formvars['table_name'].'.sql '.$this->pgdatabase->dbName.' '.$this->pgdatabase->dbName);
+durch
+ exec(POSTGRESBINPATH.'psql -f '.IMAGEPATH.$this->formvars['table_name'].'.sql '.$this->pgdatabase->dbName.' '.$this->pgdatabase->user);
+ersetzen.
+Damit die Anzahl der eingelesenen Datensätze auch noch richtig angezeigt wird, die Zeile
+ showAlert('Import erfolgreich. Die Tabelle '.$this->formvars['table_name'].' wurde erzeugt und '.count.' Datensätze eingelesen.');
+durch
+ showAlert('Import erfolgreich. Die Tabelle '.$this->formvars['table_name'].' wurde erzeugt und '.$count.' Datensätze eingelesen.');
+ersetzen.
+== + Stellenauswahl ==
+--SigridP 08:48, 12. Jun 2007 (CEST)Nach dem Befehl "Stelle Wählen" und der Auswahl einer neuen Stelle + "WEITER" kommt die Meldung:
+ Fehler beim Wechseln der Stelle. Prüfen Sie die Angaben.
+Dabei wird unter aktuelle Kartenausdehnung: die Eintragung"undefined" durch die Koordinaten ersetzt. Bei erneutem Betätigen von "WEITER" funktioniert der Stellenwechsel.
+:--[[Benutzer:Rahn|Rahn]] 10:45, 13. Jul 2007 (CEST) Bei einigen lag der Fehler daran, dass 2 Konstanten in der der php.ini falsch gesetzt waren. Beide müssen auf OFF gesetzt sein:
+ magic_quotes_gpc = Off
+ magic_quotes_runtime = Off
+= Version 1.6.4 =
+== + Fehler in Flurstücksabfrage aus der Grafik bei räumlichen Fliter ==
+--[[Benutzer:HolgerR|HolgerR]] 09:08, 12. Jun 2007 (CEST)
+Bei der Flurstueckssuche ueber die Grafik tritt bei Stellen, deren Flurstuecksanzeige durch einen raeumlichen Filter begrenzt ist, ein Fehler auf. In meinem Fall ist als Filterkriterium die 'gemeinde' hinterlegt.
+In der phplog erfolgt folgender Eintrag:
+ [08-Jun-2007 12:35:51] PHP Warning:  pg_query(): Query failed: ERROR: column "gemeinde" does not exist in /srv/www/htdocs/kvwmap_svg/class/postgresql.php on line 3640
+Haengt das vielleicht mit dem Statment in der Spalte 'pfad' zusammen? Da wird ja das Attribut als 'template erforderlich'::text AS gemeinde
+hinterlegt. Kann php / PostgeSQL das so nicht auswerten? Ich nutze PostgreSQL in der Version 8.1.3 und php in der Version 4.3.10.
+Was kann ich tun, um den Fehler zu umgehen?
+:Hallo Holger,
+:
+:da hast Du ein Problem entdeckt, was wir beim Erstellen des Pfad-Statements für den Layer Flurstücke nicht bedacht hatten. Alle abgefragten Attribute im Pfad-Statement sind ja praktisch Pseudo-Attribute, das heißt sie kommen nicht aus den Tabellen, sondern haben alle den Wert 'Template erforderlich' und werden nur deshalb im Select aufgeführt, um die Rechte für die einzelnen Attribute setzen zu können. Die eigentlich Abfrage der Sachdaten erfolgt dann im Template über readALBdata().
+:Macht man eine Abfrage auf den Flurstückslayer, der einen Filter enthält, so funktioniert der Filter natürlich nicht, weil es ja ,wie gesagt keine richtigen Attribute sind. Um wieder nach Attributen filtern zu können, muss man die entsprechenden Attribute korrekt ins Pfad-Statement einbauen. Für das Attribut gemeinde also z.B. so
+ select alkf.flurstkennz, 'template_erforderlich'::text AS flurnr, 'template_erforderlich'::text AS entsteh, 'template_erforderlich'::text AS letzff, 'template_erforderlich'::text AS flaeche, 'template_erforderlich'::text AS karte, 'template_erforderlich'::text AS kreisid, 'template_erforderlich'::text AS kreisname, 'template_erforderlich'::text AS gemkgschl, 'template_erforderlich'::text AS gemkgname, gemkg.gemeinde AS gemeinde, 'template_erforderlich'::text AS gemeindename,'template_erforderlich'::text AS finanzamt,'template erforderlich'::text AS finanzamtname, 'template_erforderlich'::text AS forstschluessel, 'template_erforderlich'::text AS forstname, 'template_erforderlich'::text AS lagebezeichnung, 'template erforderlich'::text AS nutzung, 'template erforderlich'::text AS ausfstelle,'template erforderlich'::text AS verfahren, 'template erforderlich'::text AS vorgaenger, 'template erforderlich'::text AS bestandsnr,'template erforderlich'::text AS eigentuemer, 'template erforderlich'::text AS freitext, 'template erforderlich'::text AS hinweis,'template erforderlich'::text AS baulasten, 'template erforderlich'::text AS amtsgerichtname, 'template erforderlich'::text AS amtsgerichtnr,'template erforderlich'::text AS grundbuchbezirkname, 'template erforderlich'::text AS grundbuchbezirkschl, 'template erforderlich' AS klassifizierung
+ FROM alknflst as alkf, alkobj_e_fla AS alko, alb_v_gemarkungen as gemkg
+ WHERE alko.folie='001' AND alko.objnr = alkf.objnr AND gemkg.gemkgschl = alkf.gemkgschl
+:Gruß,
+:Stefan
+::In der Spaltendeklaration reicht m.E. weiterhin das 'template erforderlich', Hauptsache in der FROM- und WHERE - Klausel sind die richtigen Eintragungen gemacht.
+::Holger
+== + Flurstückssuche - Anzeige in der Karte - Abbruch in Zeile 8791 ==
+--[[Benutzer:HolgerR|HolgerR]] 09:00, 1. Jun 2007 (CEST)
+Wird bei wiederholter Flurstückssuche das herausgefilterte Flurstück über 'Kartenausschnitt' in der Karte präsentiert und das Suchergebnis nicht gelöscht, so erscheint ab der zweiten Präsentation eines Flurstücks oberhalb der Karte die Ausschrift:
+ Abbruch in Zeile 8791
+Der Abbruch erfolgt in kvwmap.php in der Function 'new_Style'.
+In der Tabelle 'styles' wird beim erstmaligen Anlegen des temporären Styles für das herausgefilterte und anzuzeigende Flurstück ein Style mit der 'style_id' '0' angelegt. Für die darauffolgenden Suchergebnisse wird wieder versucht ein Style mit der ID '0' anzulegen. Da aber die Spalte 'style_id' als Primärschlüssel definiert ist, kommt es hier zur Kollision.
+Abhilfe schafft u.a. das Zuweisen von 'AUTO_INCREMENT' auf die Spalte 'Style_ID' mit folgendem Befehl
+ ALTER TABLE styles CHANGE COLUMN Style_ID INT NOT NULL AUTO_INCREMENT;
+Da ja schon Daten in der Tabelle enthalten sind ist es notwendig mit
+ ALTER TABLE styles AUTO_INCREMENT = wert;
+den Autowert auf den höchsten freien Wert einzustellen.
+Das ist ein datenbankseitiger Lösungsvorschlag. Eventuell kann das ja auch programmseitig abgefangen werden? Stefan, Peter habt ihr da eine Lösung?
+:--[[Benutzer:HolgerR|HolgerR]] 13:01, 5. Jun 2007 (CEST) Beim Erstellen der MySQL-Datenbank mit Hilfe der zur Verfügung gestellten SQL-Skripts tritt dieser Fehler nicht auf, da hier die Spalte 'style_id' auf 'AUTO_INCREMENT' eingestellt wird. Zu diesem Fehler braucht also nichts weiter getan werden.
+== - Fehlerhafte Angaben bei der Ausgabe des zuständigen Grundbuchamts ==
+--[[Benutzer:Giese|FrankGiese]] 15:22, 16. Mai 2007 (CEST)
+Ich musste feststellen, dass bei unseren ALB-Auszügen teilweise falsche Angaben zum zuständigen Grundbuchamt ausgegeben werden.
+Mit der ersten Abfrage habe ich bis zu 9 Grundbuchbezirke in einer Gemarkung  gefunden. Kvwmap gibt aber nur den ersten gefundenen Datensatz heraus. Wenn er zufällig, wie in meinem Fall ein Grundbuchamt im Nachbarkreis bezeichnet, wird diese Angabe für die gesamte Gemarkung benutzt.
+Für Abfrage nach Grundbuchbezirksnummern in einer ausgewählten Gemarkung
+SELECT DISTINCT gb.amtsgericht AS schluessel,a.name, gb.grundbuchbezschl, f.gemkgschl
+FROM alb_g_buchungen AS b,alb_flurstuecke AS f,alb_v_grundbuchbezirke AS gb,alb_v_amtsgerichte AS
+a WHERE gb.grundbuchbezschl=b.bezirk AND b.flurstkennz=f.flurstkennz AND gb.amtsgericht=a.amtsgericht AND f.gemkgschl=130621
+Für Abfrage nach Grundbuchbezirksnummern in einer ausgewählten Gemarkung wenn zusätzlich die Blattnummer ausgegeben werden soll
+SELECT DISTINCT gb.amtsgericht AS schluessel,a.name, gb.grundbuchbezschl, f.gemkgschl, b.blatt
+FROM alb_g_buchungen AS b,alb_flurstuecke AS f,alb_v_grundbuchbezirke AS gb,alb_v_amtsgerichte AS
+a WHERE gb.grundbuchbezschl=b.bezirk AND b.flurstkennz=f.flurstkennz AND gb.amtsgericht=a.amtsgericht AND f.gemkgschl=130621
+== + Infoabfrage auf Punktlayer der PostGIS ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:14, 16. Mai 2007 (CEST)<br>
+Abfragen auf Punktobjekte, die aus der DB stammen, scheitern bei einfachem Klick in die Karte - man muss ein Rechteck aufziehen. Alle Einträge bei "tolerance" werden nicht beachtet.
+== + Mehrere Hinweise zu einem Flurstück ==
+--[[Benutzer:A.tower|Andreas Thurm]] 11:13, 2. Mai 2007 (CEST) Wenn zu einem Flurstück in der Tabelle alb_f_hinweise mehrere Hinweise (also auch mehrere Zeilen) vorhanden sind, wird nur der erste Hinweis im ALB-Auszug und in der Sachdatenanzeige berücksichtigt.
+== + fehlende Maßstabseingabe ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 07:46, 26. Apr 2007 (CEST)<br>
+Wenn man die Maßstabsangabe im Feld unter der Karte löscht, aber keinen neuen Wert eingibt, dann gibts bei der nächsten Aktion (zoomen, pannen etc.) nur noch eine Fehlermeldung. Das müßte abgefangen werden.
+== - PDF-Ausgabe "für alle Flurstücke" bei sehr vielen Flurstücken ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 15:35, 17. Apr 2007 (CEST)<br>
+Bei einer sehr großen Zahl von Flurstücken in der Sachdatenanzeige Flurstücke funktioniert die PDF-Ausgabe "für alle Flurstücke" nicht mehr, es kommt nach längerer Zeit lediglich eine nichtssagende Fehlermeldung.
+== + Adresssuche bei der ersten Straße einer Gemeinde ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 15:35, 17. Apr 2007 (CEST)<br>
+Bei der Adresssuche kann man (immer noch nicht) nach den Hausnummern der ersten angezeigten Straße suchen.
+== - Probleme mit Druckrahmen ==
+--[[Benutzer:Hschmidt|Hschmidt]] 10:26, 17. Apr 2007 (CEST) <br>
+* Wenn man einer Stelle nur einen Druckrahmen zugeordnet hat, kann man keine Druckvorschau produzieren, weil kein Druckaussschnitt gewählt werden kann.
+* Beim Druckrahmeneditor (go=Druckrahmen) lässt sich ein Wasserzeichen einfügen, aber nicht nachträglich löschen. Änderungen werden nicht gespeichert. Ebenso scheinen Probleme bei der Änderung von Eintragungen im Feld  "ursprünglicher Maßstab" zu bestehen.
+== - ALB 20 u. 25 | fehlende Ausgabe von Miteigentumsanteil u.a. ==
+--[[Benutzer:Hschmidt|Hschmidt]] 11:12, 16. Apr 2007 (CEST)<br>
+Bei der Ausgabe der ALB-Formate 20 uund 25 fehlen die Angaben zum Miteigentumsanteil, Sondereigentum und Aufteilungsplan-Nr.. Diese Angaben befinden sich in der Tabelle "alb_b_grundstuecke" in den Spalten "anteil", "sondereigentum" und "auftplannr".
+== + Klassen ausblenden ==
+--[[Benutzer:Hschmidt|Hschmidt]] 11:55, 12. Apr 2007 (CEST)<BR>
+Die Datei gui.php aus dem custom-Ordner dieser Version enthält nicht die neue Funktion "updateclasses" mit dem Klassen der Layer in der Legende ausgeblendet werden können. Als Vorlage für eine custom-GUI sollte man die Datei gui.php aus dem layouts-Ordner verwenden.
+== + Druckprobleme ==
+--[[Benutzer:Hschmidt|Hschmidt]] 14:38, 5. Apr 2007 (CEST), geändert 31.05.07
+* Beim Druck treten Fehlermeldungen auf bzgl. unzureichender Schreib-Rechte auf das Verzeichnis " PDFClass/fonts ". Abhilfe kann man sich verschaffen indem man die Rechte entprechend hoch setzt (z.B. 777).
+* Der Adobe Reader meldet nach Erstellung der PDF-Datei in einem Fensterchen "In der Schrift "php_Times-Roman" ist der Wert für /BBox fehlerhaft.". Abhilfe kann man sich verschaffen indem man die entsprende Schrift ohne "php_" verwendet z.B.: Times-Roman statt php_Times-Roman.
+* Das bei den Anwendern sehr beliebte direkte Drucken in eine PDF-Datei (go=ExportMapToPDF) funktioniert nicht mehr :-(
+:--[[Benutzer:Rahn|Rahn]] 13:45, 31. Mai 2007 (CEST) Geht in der 1.6.5 wieder
+* Bei schwacher Netzanbindung kann es zu Problemen kommen die PDF-Dateien im Browser-Plugin zu öffnen. Der Vorgang wird abgebrochen und  der Browser meldet "angehalten". Abhilfe bringt die Änderung des Umgangs mit den PDF-Dateien in den Browsereinstellungen. Bei Firefox ab Ver. 2.0 unter "Extras | Einstellungen | Inhalt | Dateitypen verwalten ..." Dort PDF auswählen und "Aktion ändern" in "Dateien auf Diskette/Festplatte speichern". Dann wird die Datei erst heruntergeladen und kann im Download-Fensterchen problemlos geöffnet werden. Irgendwie scheint das aber ein kvwmap-spezifisches Problem zu sein, weil an den entsprechenden Arbeitsplätzen andere PDFs (auch größere) problemlos im Plugin geöffnet werden können!
+== - Shape-Export ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 11:45, 2. Apr 2007 (CEST)
+* Umlaute in Layernamen bzw. dann im Shapenamen müssten in "Ae", "ae" usw. gewandelt werden, sonst kann der Shape nicht gedownloaded werden und hat auch nicht den richtigen Namen.
+* Beim Eingrenzen über ein Polygon tauchen im SQL-Statement Backslashes auf, mit denen zumindest meine Postgres-Version 7.4.8 nichts anfangen kann.
+:--[[Benutzer:Rahn|Rahn]] 14:11, 2. Apr 2007 (CEST) Warum die Backslashes bei einigen auftauchen und bei einigen nicht, ist noch nicht geklärt. Um sie zu entfernen in kvwmap.php in der Funktion shp_export_exportieren nach der Zeile
+ $sql = $this->formvars['selectstring'];
+die Zeile
+ $sql = str_replace("\\", "", $sql);
+einfügen.<br>
+*--[[Benutzer:Markus Hentschel|Markus Hentschel]] 11:45, 16. Mai 2007 (CEST) Wenn ich eine Shapedatei erzeuge, bekomme ich nach dem Alert-Fenster mit der Meldung des erfolgreichen Erzeugens des Shapes eine Fehlermeldung:
+ Warning: unlink(/srv/www/htdocs/tmp/shp_Export_Fluren509/Fluren.shp) [function.unlink]: No such file /
+ or directory in /srv/www/htdocs/kvwmap/class/kvwmap.php on line 3265
+Der anschließende Klick auf "Herunterladen" funktioniert nicht, weil die zip-Datei im tmp-Verzeichnis nicht existiert.
+= Version 1.6.3 =
+== + Fachschale Jagdkataster | Tabelle Jagdbezirke ==
+--[[Benutzer:Hschmidt|Hschmidt]] 11:32, 26. Mär 2007 (CEST)<br>
+In der Tabelle jagdbezirke fehlt offensichtlich die Spalte "name". Beim Versuch einen Datensatz abzuspeichern kommt die entspr. Fehlermeldung.
+== + Druckrahmen - 'als neuen Rahmen speichern' - Referenzkarte ==
+--[[Benutzer:HolgerR|HolgerR]] 16:02, 22. Mär 2007 (CET)
+Beim Anlegen von Druckrahmen auf Basis vorhandener Druckrahmen wird bei Nichtvorhandensein einer Referenzkarte der Stringwert 'NULL' in die Tabelle 'druckrahmen' in das Feld 'refmapsrc' eingetragen. Beim Aufruf dieses Rahmens bricht kvwmap mit einem weißen Bildschirm ab.
+Eine einfache Lösung besteht darin, in phpMyAdmin das Feld 'refmapsrc' auf NULL zu setzen. Beim Anlegen mehrer Rahmen ist das ganz schön umständlich. Daher habe ich die Funktionen wie folgt angepasst [[Änderungen]]
+== + ALB-Einleseroutine: Hinweise zum Flurstück ==
+--[[Benutzer:A.tower|Andreas Thurm]] 08:34, 16. Mär 2007 (CET)
+Mir ist aufgefallen, dass Hinweise zum Flurstück, welche im ALB gelöscht worden sind in kvwmap noch vorhanden sind.
+:--[[Benutzer:HolgerR|HolgerR]] 15:51, 22. Mär 2007 (CET)
+:Andreas siehe mal meinen Hinweis zur Version 1.6.2: [http://kvwmap.geoinformatik.uni-rostock.de/index.php/Bug_kvwmap#-_ALB_Fortfuehrungsart_57_-_Loeschen_der_alten_Eintraege_f.C3.BCr_Hinweise_und_Verfahren Hinweis]
+== + Löschen von Freitexten ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 11:37, 8. Mär 2007 (CET)
+Wenn ich in der druckrahmenverwaltung einen Freitext lösche, lande ich anschließend nicht in meiner bearbeiteten Druckvorlage, sondern in der "aktuellen Druckvorlage". Frage: Ist das mit der "aktuellen Druckvorlage" überhaupt nötig?
+== + ALB-Formate 20 und 25 ohne Wasserzeichen ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 14:07, 2. Mär 2007 (CET)
+Obwohl ich die Funktion "ohneWasserzeichen" einer Stelle nicht zugeordnet habe, erscheint der Link "ohne WZ" sowohl bei ALB-Auszug 20 als auch bei ALB-Auszug 25 und das PDF wird erzeugt.
+== + Suchknopf über Fenster in der Dokumentenrecherche ==
+--[[Benutzer:M.Leschke|M.Leschke]] 15:55, 19. Feb 2007 (CET)
+In der Dokumentenrecherche der Nachweisverwaltung wird der Auswahlknopf über Viereck nicht als aktiv (gelb) dargestellt. Außerdem  muß er bei der ersten Benutzung mit Doppelklick und später mit einfachem Klick aktiviert werden. Das Gleiche gilt für den Umringspolygon-löschen Knopf in der Nachweisverwaltung.
+== - ALB-Einleseroutine - Baulasten hist. Flurstuecke ==
+--[[Benutzer:HolgerR|HolgerR]] 09:29, 9. Feb 2007 (CET)
+Die Baulastenblätter von untergegangenen Flurstücken werden weiter in der Datenbank vorgehalten. Ist das so gewollt? m.E. nach wird eine ausgefeilte Flurstückshistorie zum derzeitigen Stand in kvwmap nicht geführt und die Daten sind somit nicht mehr notwendig.
+Lt. dem SQL-Dump werden die Angaben zwar zuerst gelöscht, aber anschließend wieder der Tabelle alb_f_baulasten angefügt.
+ INSERT INTO alb_x_flurstuecke (flurstkennz,gemkgschl,flurnr,pruefzeichen) VALUES ('132311-001-00193/003.00','132311','001','4');
+ UPDATE alb_x_flurstuecke SET flurstkennz='132311-001-00193/003.00',status='H',entsteh='2005/03019-11',letzff='2006/03544-11',flaeche=144511,aktunr=03 WHERE flurstkennz='132311-001-00193/003.00';
+ INSERT INTO alb_x_f_baulasten (flurstkennz,blattnr) VALUES ('132311-001-00193/003.00','40002');
+ DELETE FROM alb_f_baulasten USING alb_x_f_baulasten WHERE alb_f_baulasten.flurstkennz=alb_x_f_baulasten.flurstkennz;
+ INSERT INTO alb_f_baulasten SELECT * FROM alb_x_f_baulasten;
+Die Einleseroutine müsste so weit verbessert werden, das beim 1. INSERT zu alb_x_f_baulasten der Status 'H' des Flurstückes mit ausgewertet wird und diese Baulasten in die temporäre Datei nicht eingetragen wird.
+Die anderen Einleseroutinen zu den weiteren Flurstückattributen bin ich jetzt nicht durchgegangen, aber ich könnte mir vorstellen, das es hier ähnlich aussieht. z.B. Hinweise zum Flurstück aus dem SQL-Dump:
+ DELETE FROM alb_f_hinweise USING alb_x_f_hinweise WHERE alb_f_hinweise.flurstkennz=alb_x_f_hinweise.flurstkennz;
+ INSERT INTO alb_f_hinweise SELECT * FROM alb_x_f_hinweise;
+Wenn eine umfassende Flurstückhistorie gewünscht ist, könnten in diesem Fall die Funktionen deleteHistXXX aus dem Programmcode entfernt werden. Die historischen Flurstücke müssten dann aber auch in der Tabelle alb_flurstücke mit dem Status 'H' belegt und nicht gelöscht werden.
+== + ALB-Einleseroutine - deleteOldxxx ==
+--[[Benutzer:HolgerR|HolgerR]] 14:21, 8. Feb 2007 (CET)
+beim der Anzeige der Baulasten ins kvwmap ist mir aufgefallen, dass neben den untergegangenen Verfahren und Hinweisen auch die untergegangenen Baulasten nicht richtig gelöscht werden.
+Ich könnte mir vorstellen, dass die Funktionen
+*deleteOldAdressen
+*deleteOldLagen
+*deleteOldNutzungen
+*deleteOldKlassifizierungen
+*deleteOldTexte
+*deleteOldAnlieger
+*deleteOldBaulasten
+in der postgresql.php vom fehlerhaften Löschansatz betroffen sind.
+Das Problem ist, dass in der wldge keine Löschdatensätze enthalten sind. Untergegangene Flurstücke werden historisch gesetzt (Status 'H'). Bei Änderungen zum Flurstück werden nur die Änderungen mitgeteilt. Fällt jetzt ein Datensatz weg, wie z.B. eine eingetragene Baulast zu einem Flurstück, wird diese 'R'-Zeile in der wldge-Datei einfach nicht mehr aufgeführt.
+Der Abgleich zum Löschen der Baulast kann daher nicht gegen die neu eingelesen alb_x_f_baulast erfolgen - hier steht die untergegangene Baulast nicht mehr drin - , sondern der Abgleich muss im Vergleich zu allen eingelesen Flurstücken alb_x_flurstuecke erfolgen.
+Hier habe ich mal die korrigierte Fassungen der [[Funktionen]] hinterlegt
+== + Query im Polygon ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:24, 2. Feb 2007 (CET)
+Wenn ich eine Abfrage im Polygon machen will und ich mich "verpolygoniert" habe, habe ich keine Möglichkeit, das Zeichnen des Polygons abzubrechen. Auch der Klick auf einen anderen Button hilft nicht.
+:--[[Benutzer:HolgerR|HolgerR]] 13:04, 5. Feb 2007 (CET)
+:Markus vorübergehend hilft jede Aktion, die den Karteninhalt neu lädt, also 'Pan', 'Neu laden', Zoom, ...
+:Du hast aber recht, bei erneutem Anklicken des Polygonabfragebuttons müsste die Möglichkeit bestehen, den Polygon wieder neu zu zeichnen.
+::--[[Benutzer:Rahn|Rahn]] 12:04, 8. Feb 2007 (CET) Ist behoben. In der nächsten Version kann man durch einen weiteren Klick auf den Button das Polygon löschen.
+== + Selektionslayer ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:24, 2. Feb 2007 (CET)
+Wenn ein Selektionslayer gelöscht wird, indem der Benutzer den Haken rausnimmt und neu lädt, werden die entsprechenden Einträge in den Tabellen "styles2classes", "used_layer" und "rolle2used_layer" nicht gelöscht. Oder habe ich nur ein Problem mit meiner MySQL?
+:--[[Benutzer:Rahn|Rahn]] 12:49, 5. Mär 2007 (CET) Die Selektionslayer werden jetzt in der Tabelle rollenlayer gespeichert.
+== + Fehlermeldung im generischen Layereditor ==
+Beim Aufruf des generischen Layereditors kann es (je nach Postgres-Version) vorkommen, dass Fehlermeldungen angezeigt werden. Zur Behebung des Problems in postgresql.php in der Funktion pg_table_constraints() die Zeile
+ $sql = "SELECT consrc FROM pg_constraint WHERE contype = 'check'";
+durch diese hier ersetzen:
+ $sql = "SELECT consrc FROM pg_constraint, pg_class WHERE contype = 'check'";
+== + punktförmige Bodenrichtwertzonen kopieren ==
+--[[Benutzer:Certa|Certa]] 12:34, 25. Jan 2007 (CET)
+Der Versuch, punktförmige Bodenrichtwerte in einen neuen Stichtag zu kopieren, scheitert, weil die Funktion versucht, in die Spalte "textposition" der Tabelle "bw_bodenrichtwertzonen" zu schreiben. die existiert aber nicht bei punktförmigen Bodenrichtwerten. Außerdem steht in allen Masken "Bodenrichtwert'''zonen'''", obwohl ich es nicht mit Zonen, sondern mit Punkten zu tun habe.
+*--[[Benutzer:Rahn|Rahn]] 13:30, 25. Jan 2007 (CET) Um den Fehler beim Kopieren zu beheben, in bodenrichtwerte.php in der Funktion copyZonenToNewStichtag() die Zeile
+ $sql.=",sanierungsgebiete,sichtbarkeit,'".$newStichtag."',the_geom,textposition";
+durch diese Zeilen ersetzen:
+ if(BODENRICHTWERTTYP == 'punkt'){
+    $sql.=",sanierungsgebiete,sichtbarkeit,'".$newStichtag."',the_geom";
+ }
+ else{
+    $sql.=",sanierungsgebiete,sichtbarkeit,'".$newStichtag."',the_geom,textposition";
+ }
+== + Fachschale Jagdkataster ==
+Damit auch Sonderflächen erfasst werden können, muss dass entsprechende constraint der Tabelle jagdbezirke wie folgt geändert werden:
+ ALTER TABLE jagdbezirke DROP CONSTRAINT art;
+ ALTER TABLE jagdbezirke ADD CONSTRAINT art CHECK (art::text = 'gjb'::text OR art::text = 'ejb'::text OR art::text = 'tjb'::text OR art::text = 'sf'::text);
+== + Geometrien erfassen ==
+Damit in den verschiedenen Fachschalen auch Multipolygone gespeichert werden können, muss das entsprechende constraint der Tabelle wie folgt geändert werden:
+ ALTER TABLE <TABELLENNAME> DROP CONSTRAINT enforce_geotype_umring;
+ ALTER TABLE <TABELLENNAME> ADD CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) = 'POLYGON'::text OR geometrytype(the_geom) = 'MULTIPOLYGON'::text OR the_geom IS NULL);
+== - Nachweisverwaltung - Dokument überarbeiten - doppelte Dokumentnamenvergabe == --[[Benutzer:HolgerR|HolgerR]] 17:20, 16. Jan 2007 (CET)
+Wird bei der Änderung von Dokumenten der Dokumentenname eines schon vorhandenen Dokumentes generiert (z.B. Vergabe einer schon vorhanden laufenden Nummer im Dokumentenstamm) erscheint eine leere Fehlermeldung. Bitte mit Inhalt füllen, damit der Nutzer weiß, was er verkehrt gemacht hat.
+== + Attribut-Editor verweigert Änderungen ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 12:28, 16. Jan 2007 (CET)
+Ich kann im Attribut-Editor nicht die Formularelement-Einstellungen der Attribute ändern. Ich kriege folgende Fehlermeldung:
+ Warning: mysql_error(): supplied argument is not a valid MySQL-Link resource<br>in /srv/www/htdocs/kvwmap/class/mysql.php on line 2339
+== + PDF-Druckfunktion - fehlende Schrift == --[[Benutzer:HolgerR|HolgerR]] 13:42, 15. Jan 2007 (CET)
+In der PDF-Druckfunktion erhalte ich bei der Übergabe des Bildes an den Acrobat Reader folgende Fehlerausschrift:
+ Eine Schrift ist nicht im Ressourcen-Dictionary verzeichnet - Helvetica wird verwendet.
+In der phplog-Datei wird folgender Eintrag generiert:
+ [15-Jan-2007 13:15:39] PHP Warning:  Unable to set output format to 'jpeg_print' in /srv/www/htdocs/kvwmap_dev/class/kvwmap.php on line 2196
+Welche Schrift fehlt hier und wo muss die stehen? Ist da serverseitig oder clientseitig was zu tun? Ist vielleicht PHP nicht richtig compiliert?
+:--[[Benutzer:Rahn|Rahn]] 23:27, 15. Jan 2007 (CET) Diese Fehlermeldung bedeutet nur, dass eine Schriftart, die für den Druckrahmen ausgewählt wurde, nicht vom Acrobat Reader unterstützt wird (Zur Auswahl stehen ja alle Fonts der PDF-Class). Um die Fehlermeldung zu vermeiden, einfach eine andere auswählen, z.B. Helvetica.
+:Der Eintrag in der Log-Datei hat nichts mit der falschen Schriftart zu tun. Hier wurde nur protokolliert, dass für den Druck versucht wurde ein Output-Format zu setzen (jpeg_print), dass offenbar nicht definiert ist. Die Output-Formate stehen in der defaultmapfile.map. Das Format jpeg_print wurde in der Version [[Changelog#kvwmap-1.5.8|1.5.8]] eingeführt, um eine höhere Druckqualität zu erzielen (die jpg-Qualität ist hier 100%). Beim PDF-Export wird versucht, dieses Format zu setzen. Wenn dies fehlschlägt, wird das Standardformat jpeg verwendet. Es ist also nichts wirklich schlimmes, allerdings empfiehlt es sich für den Druck doch jpeg_print als Outputfprmat zu verwenden.
+== + Layer werden nicht mehr angezeigt ==
+Im Stelleneditor und nach "Layer anzeigen" kann es sein, dass die Layer nicht angezeigt werden. Dazu in der users.php in der Funktion getLayers() die Zeile
+ $sql .=' AND layer.Gruppe = u_groups.id AND NOT u_groups.Gruppenname = "Suchergebnis"';
+durch diese ersetzen:
+ $sql .=' AND layer.Gruppe = u_groups.id AND u_groups.Gruppenname != "Suchergebnis"';
+und in kvwmap.php in der Funktion getall_Layer() in die Zeile
+ $sql.=' WHERE layer.Gruppe = u_groups.id AND NOT u_groups.Gruppenname = "Suchergebnis"';
+durch diese hier:
+ $sql.=' WHERE layer.Gruppe = u_groups.id AND u_groups.Gruppenname != "Suchergebnis"';
+== + Fehler in der Flurstückssuche ==
+--[[Benutzer:Rahn|Rahn]] 10:17, 10. Jan 2007 (CET)
+Wer den Internetexplorer benutzt, dürfte beim Aufruf der Flurstückssuche bemerkt haben, dass hier nichts angezeigt wird. Zur Behebung des Bugs einfach die erste Zeile in flurstueckssuche.php:
+ <script language="JavaScript" src="funktionen/selectformfunctions.js" type="text/javascript">
+umd das fehlende End-Tag erweitern:
+ </script>
+= Version 1.6.2 =
+== + Darstellung Label - partials ==
+--[[Benutzer:HolgerR|HolgerR]] 10:11, 19. Dez 2006 (CET)
+Die Änderung der Einstellung zu der partiellen Darstellung der Label in der Tabelle 'labels', Spalte 'partials' ist ohne Wirkung. In der Mapdatei wird immer der Standardwert 'TRUE' verwandt.
+Lösung: In der Datei 'kvwmap.php' in der Funktion 'loadclasses' unterhalb von
+<pre>
+        $klasse->label->set('force',$dbLabel['the_force']);
+</pre>
+folgende Zeile einfügen
+<pre>
+        $klasse->label->set('partials',$dbLabel['partials']);
+</pre>
+== - Stellenabhängige Maßstabseinstellungen in 'used_layer' ==
+--[[Benutzer:HolgerR|HolgerR]] 11:28, 15. Dez 2006 (CET)
+In der Tabelle 'used_layer' sind zur stellenabhängigen Maßstabseinstellungen die Spalten 'minscale' und 'maxscale' hinterlegt. In der Mapdatei werden leider nur die Eintragungen aus der Tabelle 'layer' verwandt.
+== + zurück zur Flurstückssuche ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:10, 6. Dez 2006 (CET) Nach einer Flurstückssuche sollte man aus der Sachdatenanzeige heraus wieder zurück in die Flurstückssuche gehen können, wobei das zuletzt gesuchte Flurstück vorselektiert ist. Bei mir klappt das nicht. Die entsprechende FST-Nummer wird mit go=Flurstueck_Auswählen nicht übergeben.
+== + Fehler beim Überarbeiten von Dokumenten in der Nachweisverwaltung ==
+--M.Leschke 13.50, 16. Nov 2006 (CEST) Beim Überarbeiten von Dokumenten in der Nachweisverwaltung wird das Umringspolygon für den zu bearbeitenden Nachweis zwar geladen (es wird blau markiert), nach Änderung des Datensatzes (Datum oder Stammnummer)erschient aber folgende Fehlermeldung:
+ Bitte legen Sie das Umringspolygon für den einzuarbeitenden Nachweis fest.
+*--[[Benutzer:Rahn|Rahn]] 12:56, 8. Dez 2006 (CET): Zur Behebung des Fehlers in der Funktion changeDokument in nachweis.php die Zeile
+ $ret=$this->pruefeEingabedaten($formvars['datum'],$formvars['VermStelle'],$formvars['art'],$formvars['gueltigkeit'],$formvars['stammnr'],$formvars['Blattformat'],$formvars['Blattnr'],$formvars['changeDocument'],$formvars['Bilddatei_name'],$formvars['pathlength'],$formvars['pathx'],$formvars['pathy']);
+durch diese hier erseten:
+ $ret=$this->pruefeEingabedaten($formvars['datum'],$formvars['VermStelle'],$formvars['art'],$formvars['gueltigkeit'],$formvars['stammnr'],$formvars['Blattformat'],$formvars['Blattnr'],$formvars['changeDocument'],$formvars['Bilddatei_name'],$formvars['pathlength'],$formvars['umring']);
+== +- Mapserverfehler nach Betätigung Druckvorschaubutton ==
+Nach bisher nicht erkennbaren Muster sendet der Mapserver nach Betätigung des Druckvorschaubuttons gelegentlich folgende Meldung:
+ Fatal error: [MapServer Error]: msDrawLegend(): Unable to initialize image in /Pfad zu kvwmap/class/kvwmap.php on line 1082
+*--[[Benutzer:Rahn|Rahn]] 13:07, 30. Okt 2006 (CET) Ist uns auch schon aufgefallen. Warum das so zufällig auftritt, wissen wir auch noch nicht. Auf jeden Fall verursacht die Legendenerzeugung diese Fehlermeldung. Läßt man die Legende weg (Legendenbreite rausnehmen), wird man von den Fehlermeldungen verschont.
+== + Druckrahmen Änderungen speichern ==
+Versucht man im Druckrahmeneditor die vorgenommenen Änderungen an einem Druckrahmen zu speichern oder einen neuen anzulegen, kommt eine Fehlermeldung und es erfolgt keine Speicherung. Zur Behebung die Zeile
+ $sql .= ", `font_text` = '".$formvars['font_text']."'";
+in den Funktionen update_frame und save_frame in kvwmap.php löschen.
+== + Nordpfeil ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 11:54, 20. Okt 2006 (CEST) Die rechte Hälfte der Pfeilspitze sollte weiß und nicht transparent sein.
+== + Drehwinkel ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 14:18, 18. Okt 2006 (CEST) Beim Eingeben eines Drehwinkels funktioniert die Druckvorschau nicht, es kommt folgende Meldung: "Fatal error: Call to undefined function: imagerotate() in /srv/www/htdocs/kvwmap/class/kvwmap.php on line 1002"
+*--[[Benutzer:Rahn|Rahn]] 12:05, 19. Okt 2006 (CEST) Entweder Dein GD ist nicht richtig installiert, was ich aber nicht glaube oder Deine php-Version ist zu alt. Laut Dokumentation wird PHP > 4.3.0 benötigt.
+:--[[Benutzer:Markus Hentschel|Markus Hentschel]] 14:59, 19. Okt 2006 (CEST) PHP 4.3.8 ist installiert. Wie erkenne ich denn, ob meine GD nicht richtig installiert ist?
+:*--[[Benutzer:Rahn|Rahn]] 10:19, 24. Okt 2006 (CEST) Ich denke mal es liegt hier dran: In der Dokumentation zur dieser Funktion auf www.php.net steht: ''Anmerkung: Diese Funktion steht nur zur Verfügung, wenn PHP mit der GD Bibliothek übersetzt wurde, die mit PHP zusammen erhältlich ist.''
+== + Suchergebnislayer ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:59, 18. Okt 2006 (CEST) Die Layer mit Suchergebnissen dürfen nicht bei "Layer anzeigen" und "Stelle anzeigen" auftauchen.
+--SigridP 10:25, 3. Nov 2006 (CET)
+Die Layer sollten ohne Kästchen für eine Sachdatenabfrage sein, da bei Aktivschalten unnötige Fehlermeldungen erzeugt werden.
+== + PDF-Dokmente laden ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:55, 18. Okt 2006 (CEST) Mitarbeiter, die einen Umlaut im Namen haben, können PDF-Dokumente (z.B. ALB- oder Druck-Dokumente) nicht laden. Sie erhalten ein "Objekt nicht gefunden". Vorschlag: Alle Sonderzeichen aus dem Dokumentnamen entfernen (Leerzeichen und Doppelpunkte) und die Umlaute im Benutzernamen ersetzen lassen.
+*--[[Benutzer:Rahn|Rahn]] 11:48, 19. Okt 2006 (CEST) Zur Behebung in kvwmap.php in der Funktion output() die Zeile
+ $dateiname = $this->user->Name.'-'.$currenttime.'.pdf';
+durch folgende Zeilen ersetzen:
+ $name = str_replace('ä', 'ae', $this->user->Name);
+ $name = str_replace('ü', 'ue', $name);
+ $name = str_replace('ö', 'oe', $name);
+ $name = str_replace('Ä', 'Ae', $name);
+ $name = str_replace('Ü', 'Ue', $name);
+ $name = str_replace('Ö', 'Oe', $name);
+ $name = str_replace('ß', 'ss', $name);
+ $dateiname = $name.'-'.$currenttime.'.pdf';
+== + ALB-Anzeige für alle Flurstücke ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:38, 18. Okt 2006 (CEST) Die Flurstücksangaben fehlen in den PDF-Dokumenten aller Formate bei "Für alle Flurstücke".
+== + Fehler in der Flächenversiegelung ==
+Um ihn zu beheben in kvwmap.php in der Funktion versiegelungsFlaechenErfassung die Zeile
+ $GemObj=new gemeinde(0,$this->database);
+durch diese ersetzen:
+ $GemObj=new gemeinde(0,$this->pgdatabase);
+== +- Geometrieeditor: Polygon zeichnen ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 12:48, 18. Okt 2006 (CEST) Wenn ich ein Polygon zeichnen oder ein Flurstück hinzufügen will, bekomme ich im IE ein Alert: "AHAH-Error: 401 Authorization required".
+--[[Benutzer:HolgerR|HolgerR]] 10:50, 24. Nov 2006 (CET)
+Bei mir tritt der gleiche Fehler auf. In der apache-Fehlerdatei wird folgender Eintrag erzeugt:
+<pre>
+[Fri Nov 24 12:05:30 2006] [error] [client 10.32.62.45] File does not exist: /srv/www/htdocs/kvwmap_dev/10.32.0.246, ref
+erer: http://10.32.0.246/kvwmap_dev/index.php
+</pre>
+Hallo, ich habe da einen Fehler im Quellcode gefunden:
+In class/spatial_processor.php in class spatial_processor in Funktion spatial_processor
+Befinden sich zwei syntaktisch falsche Zeilen:
+  $this->$conn_id = $this->database->open();
+  $this->$pgconn_id = $this->pgdatabase->open();
+Diese müssen heißen:
+  $this->conn_id = $this->database->open();
+  $this->pgconn_id = $this->pgdatabase->open();
+Vielleicht leigt es ja daran, dass einige PHP-Processoren das akzeptieren, anderen nicht.
+In Ndbg hat das zumindest weitergeholfen.
+Peter
+== + ALB-Daten werden nicht angezeigt ==
+Bei den ALB-Auszügen fehlen sämtliche Daten zum Flurstück. Um dies zu beheben, in alb.php in der Funktion ALBAuszug_Flurstueck die Zeile
+ $ret=$flst->readALB_Data($FlurstKennz);
+durch diese ersetzen:
+ $ret=$flst->readALB_Data($FlurstKennz[$f]);
+== + History-Buttons ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:08, 17. Okt 2006 (CEST) Die beiden History-Buttons funktionieren nicht mehr.
+*--[[Benutzer:Rahn|Rahn]] 13:53, 19. Okt 2006 (CEST) Zur Behebung in users.php in der Funktion setConsumeActivity die Zeile
+ if ($prev=="0000-00-00 00:00:00" OR $prev==<nowiki>''</nowiki>) {
+durch diese ersetzen:
+ if ($prevtime=="0000-00-00 00:00:00" OR $prevtime==<nowiki>''</nowiki>) {
+== + ALB-Auszüge für alle aufgelisteten Flurstücke ==
+Das Wasserzeichen erscheint nur auf der ersten Seite, aber nicht mehr auf allen folgenden.
+--[[Benutzer:Rahn|Rahn]] 11:56, 18. Okt 2006 (CEST) Zur Behebung in alb.php in der Funktion ALBAuszug_Flurstueck die Zeilen
+ if ($wasserzeichen) {
+    $pdf->addJpegFromFile(WWWROOT.APPLVERSION.WASSERZEICHEN,75,140,450); # 2005-12-15 pk
+ }
+ausschneiden und hinter die Zeile
+ for($f = 0; $f < count($FlurstKennz); $f++){
+einfügen.
+== + Polygon löschen bei der Dokumenteneingabe==
+Im Geometrieeditor der Dokumenteneingabe hat sich ein kleiner Fehler eingeschlichen. Will man ein gezeichnetes Polygon wieder löschen, so funktioniert dies nicht und es kommt (im IE) eine Fehlermeldung. Zur Behebung des Problems in SVG_Polygon.php folgende Zeile unter "formular-variabeln fuer fachschale" einfügen:
+ <input name="area" type="hidden" value="">
+== + Geometrieeditor Bodenrichtwertzonen erfassen==
+Hier gibt es genau denselben Fehler. Hier zur Fehlerbehebung die Datei SVG_polygon_and_point.php um die Zeile
+ <input name="area" type="hidden" value="">
+erweitern.
+== + Löschen eines Suchergebnisses ==
+Zur Zeit kann man die Suchergebnislayer nur in der Layerverwaltung löschen. Ersetzt man die Funktion setAktivLAyer in users.php durch folgenden Code, wird der Suchergebnislayer durch Wegnehmen des Hakens und anschließendes neu laden gelöscht.
+ function setAktivLayer($formvars, $stelle_id, $user_id) {
+    # Eintragen des Status der Layer, 1 angezeigt oder 0 nicht.
+    for ($i=0;$i<count($this->layerset);$i++) {
+      if ($formvars['thema'.$this->layerset[$i]['Layer_ID']]==1) {
+        $aktiv_status=1;
+      }
+      elseif($formvars['thema'.$this->layerset[$i]['Layer_ID']]==2) {
+        $aktiv_status=2;
+      }
+      else{
+        $aktiv_status=0;
+      }
+      $sql ='UPDATE u_rolle2used_layer SET aktivStatus="'.$aktiv_status.'"';
+      $sql.=' WHERE user_id='.$this->user_id.' AND stelle_id='.$this->stelle_id;
+      $sql.=' AND layer_id='.$this->layerset[$i]['Layer_ID'];
+      $this->debug->write("file:users.php class:rolle->setAktivLayer - Speichern der aktiven Layer zur Rolle:",4);
+      $this->database->execSQL($sql,4, $this->loglevel);
+      // -------------- new
+      if($aktiv_status == 0){
+         $mapdb = new db_mapObj($stelle_id, $user_id);
+            $Gruppe = $mapdb->read_Group($this->layerset[$i]['Gruppe']);
+            if($Gruppe['Gruppenname'] == 'Suchergebnis'){
+               $mapdb->deleteLayer($this->layerset[$i]['Layer_ID']);
+               # auch die Klassen löschen
+               $classes = $mapdb->read_Classes($this->layerset[$i]['Layer_ID']);
+               for($j = 0; $j < count($classes); $j++){
+                  $mapdb->delete_Class($classes[$j]['Class_ID']);
+               }
+               $layer[] = $this->layerset[$i]['Layer_ID'];
+               $stelle[] = $stelle_id;
+               $Stelle = new Stelle($stelle_id, $this->database);        # <----- Zeile war fehlerhaft
+               $Stelle->deleteLayer($layer);
+               $this->deleteLayer($user_id, $stelle, $layer);
+            }
+       }
+      // --------------- new
+    }
+    return 1;
+  }
+--SigridP 11:54, 13. Okt 2006 (CEST) Bei mir kommt dann folgende Fehlermeldung:
+ Warning: Missing argument 2 for setaktivlayer() in /srv/www/htdocs/kvwmap-1.6.2/class/users.php on line 905<br>
+ Warning: Missing argument 3 for setaktivlayer() in /srv/www/htdocs/kvwmap-1.6.2/class/users.php on line 905
+--[[Benutzer:Rahn|Rahn]] 13:19, 13. Okt 2006 (CEST) Stimmt, man muss natürlich auch noch den Aufruf der Funktion in kvwmap.php
+ $this->user->rolle->setAktivLayer($this->formvars);
+so anpassen:
+ $this->user->rolle->setAktivLayer($this->formvars,$this->Stelle->id,$this->user->id);
+:--[[Benutzer:Markus Hentschel|Markus Hentschel]] 12:41, 17. Okt 2006 (CEST) Besser wäre vielleicht, wenn das Suchergebnis in die PostGIS und nicht in die MySQL geschrieben wird. Es ist unheimlich schwierig, neue Layer mit Classes etc. anzulegen, wenn alle naselang neue Layer von kvwmap angelegt werden und die nächsthöhere ID beanspruchen. Und zur Anzeige am Bildschirm: Bei mir wird jetzt in der Themenauswahl als Suchergebnis nicht die komplette Flurstücksnummer, sondern nur Gemarkung-Flur ausgegeben. Außerdem steht da immer "Flurstücke:", wäre Singular nicht sinnvoller?
+== + Leere letzte Seite bei den ALB-Auszügen  ==
+Bei allen Flurstücks-ALB-Auszügen wird noch eine leere letzte Seite hinten angehängt. Wen 's stört kann in alb.php '''!! am Ende !!''' der Funktion ALBAuszug_Flurstueck() die Zeile
+ $pageid=$pdf->newPage();
+durch folgende Zeilen ersetzen.
+ if($f < count($FlurstKennz)-1){
+    $pageid=$pdf->newPage();
+ }
+== - ALB Fortfuehrungsart 57 - Loeschen der alten Eintraege für Hinweise und Verfahren == --[[Benutzer:HolgerR|HolgerR]] 15:21, 12. Okt 2006 (CEST)
+Bei der Fortfuehrungsart 57 werden bei mehreren Flurstuecken folgende Angaben uebereinstimmend veraendert:
+:Kennung - Bezeichnung
+:D - Flurkarte, Riss; Baublock; Finanzamtszugehoerigkeit; Fortsamtszugehoerigkeit
+:U - Ausfuehrende Stelle / Verfahren
+:F - Hinweise zum Flurstueck.
+Diese Angaben koennen eingetragen, geaendert oder geloescht werden.
+Bei Eintragungen und Aenderungen laeuft alles wie es soll, da die ensprechenden Kennungen in der WLDGe enthalten sind und die Einleseroutine darauf reagieren kann.
+Fallen diese Angaben zu den Flurstuecken weg, wird in der WLDGe kein Loeschsatz erzeugt, sondern die Angaben werden einfach nicht mit aufgefuehrt. Darauf reagiert der WLDGE2SQL-Konverter bislang noch nicht, auch nicht in vorhergehenden Versionen. Dadurch existieren in der ALB-Anwendung z.B. Flurstuecke mit Verfahrenseintraegen, die so nicht mehr gueltig sind.
+Daraus ergeben sich m.E. folgende Konsequenzen:
+Die alten Eintragungen in den Tabellen `alb_f_hinweise` und `alb_f_verfahren` sind in Uebereinstimmung mit den Flurstueckskennzeichen aus der WLDGe, die in der temporaeren Tabelle `alb_x_flurstuecke` enthalten sind, zu loeschen. Dies betrifft die Funktionen `deleteOldVerfahren()` und `deleteOldHinweise()` in `postgresql.php`.
+Die korrigierte Funktion `deleteOldVerfahren()` sieht wie folgt aus:
+  function deleteOldVerfahren() {
+    $sql ="DELETE FROM alb_f_verfahren";
+    #Eingefügt 11.04.2006 H. Riedel
+    if(POSTGRESVERSION == '8.1'){
+      $sql.=" USING alb_".$this->tableprefix."flurstuecke";
+    }
+    $sql.=" WHERE alb_f_verfahren.flurstkennz=alb_".$this->tableprefix."flurstuecke.flurstkennz";
+    return $this->execSQL($sql, 4, 0);
+  }
+und die Funktion `deleteOldHinweise()` wie folgt:
+  function deleteOldHinweise() {
+    $sql ="DELETE FROM alb_f_hinweise";
+    #Eingefügt 11.04.2006 H. Riedel
+    if(POSTGRESVERSION == '8.1'){
+      $sql.=" USING alb_".$this->tableprefix."flurstuecke";
+    }
+    $sql.=" WHERE alb_f_hinweise.flurstkennz=alb_".$this->tableprefix."flurstuecke.flurstkennz";
+    return $this->execSQL($sql, 4, 0);
+  }
+Um die Werte in der Datenbank zu aktualisieren sind abschließend die ganzen BZSN, angefangen bei der Grundausstattung, neu einzulesen.
+= Version 1.6.1 =
+== + Anzeige und Drucken von ALB-Auszug 20 und ALB-Auszug 25 falsch ==
+--[[Benutzer:Rahn|Rahn]] 10:07, 2. Okt 2006 (CEST) Beim ALB-Auszug 20 und 25, dann darf der Eigentümer nur einmal erscheinen. Zur Zeit ist es so, dass der Eigentümer für jedes Flurstück, dass im Grundbuchblatt geführt ist, erneut aufgeführt wird.
+:--[[Benutzer:Rahn|Rahn]] 11:00, 2. Okt 2006 (CEST) Diesen und noch ein paar andere Fehler bei den ALB-Auszügen 20 und 25 behoben.
+== + Eigentümernachweis im ALB-Auszug ==
+--SigridP 12:39, 20. Sep 2006 (CEST)<br>
+Der im Original-ALB-Auszug zu den Privatpersonen angegebene Zusatz "GbR ......" 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.
+:--[[Benutzer:Rahn|Rahn]] 11:08, 2. Okt 2006 (CEST) In welchen ALB-Formaten ist denn dieser Zusatz erforderlich?
+--SigridP 09:36, 5. Okt 2006 (CEST)In allen ALB-Ausdrucken, in denen die Eigentümer aufgeführt werden.
+== + Fehler und Abweichungen beim ALB-Druck ==
+--[[Benutzer:Heinz Schmidt|Heinz Schmidt]] 13:29, 14. Sep 2006 (CEST)<br>
+'''was fehlt:''' <br>
+"Gesetzliche Klassifizierung" (wird, wenn vorh. im orig. ALB unter "Tatsächliche Nutzung" ausgegeben)
+* debug: --[[Benutzer:Pkorduan|Pkorduan]] 16:15, 14. Sep 2006 (CEST) Ok, das fehlt wirklich. Hier ist kein Fehler oder fehlende Daten im ALB, sondern tatsächlich im Quellcode. Zum Debuggen bitte folgende Änderung in postgresql.php  in der Funktion getKlassifizierung($FlurstKennz) vornehmen:
+an Stelle von:
+ return $Klassifizierung;
+folgendes eintragen:
+ $ret[1]=$Klassifizierung;
+ return $ret;
+Wer noch möchte, dass das Wort "Summe" groß ausgegeben wird in der ALB-Anzeige, muss die Zeile in alb.php in Funktion ALBAuszug_Flurstueck($FlurstKennz,$formnummer,$wasserzeichen) so aussehen:
+ $pdf->addText($col0,$row-=12,$fontSize,'Summe');
+"Ausführende Stelle" (wird, wenn vorh. im orig. ALB unter "Hinweise" ausgegeben)<br>
+* debug: --[[Benutzer:Pkorduan|Pkorduan]] 15:06, 14. Sep 2006 (CEST) debug: Ein Statement der Art
+ SELECT st.ausfstelle AS ausfstelleid,st.name AS ausfstellename,v.flurstkennz,
+ v.verfnr,v.verfbem AS verfbemid,b.bezeichnung AS verfbemerkung
+ FROM alb_f_verfahren AS v,alb_v_ausfuehrendestellen AS st,alb_v_bemerkgzumverfahren AS b
+ WHERE v.ausfstelle=st.ausfstelle AND v.verfbem=b.verfbem
+ AND v.flurstkennz='132295-001- 00003/008.00'
+sollte zu einer Ausgabe der ausführenden Stelle führen, aber nur, wenn da auch ein Verfahren läuft auf dem Flurstück und wenn eine Bemerkung zum Verfahren gespeichert ist.
+Da dies offensichtlich nicht immer der Fall ist, z.B. in LWL, dann muss das Statement anders lauten und zwar so, dass die Ausführende Stelle auch angezeigt wird, obwohl nicht gespeichert ist was ausgeführt wird (das sollte nähmlich in verfbem stehen)
+Ändern Sie also das SQL-Statement in der Datei postgresql.php in der Funktion function getVerfahren($FlurstKennz) Die Zeilen mit $sql folgendermaßen:
+ $sql ="SELECT st.ausfstelle AS ausfstelleid,st.name AS ausfstellename";
+ $sql.=",v.flurstkennz,v.verfnr,v.verfbem AS verfbemid,b.bezeichnung AS verfbemerkung";
+ $sql.=" FROM alb_f_verfahren AS v LEFT JOIN alb_v_bemerkgzumverfahren AS b ON v.verfbem=b.verfbem";
+ $sql.=",alb_v_ausfuehrendestellen AS st WHERE v.ausfstelle=st.ausfstelle";
+ $sql.=" AND v.flurstkennz='".$FlurstKennz."'";
+Darin ist der LEFT JOIN zwischen alb_v_bemerkgzumverfahren und alb_f_verfahren enthalten.
+--[[Benutzer:Heinz Schmidt|Heinz Schmidt]] 12:43, 18. Sep 2006 (CEST)<br>
+'''Was jetzt noch fehlt zur "Ausführenden Stelle":'''<br>
+Wenn mehrere "Ausführenden Stellen" eingetragen sind, kommt momentan nur eine.
+Ok, das ist jetzt behoben durch zwei Änderungen. Die erste Änderung in postgresql.php in Funktion getVerfahren($FlurstKennz) die Zeile:
+ $ret[1]=pg_fetch_array($queryret[1]);
+ersetzen durch die Zeilen:
+ while($rs=pg_fetch_array($queryret[1])) {
+   $Verfahren[]=$rs;
+ }
+ $ret[1]=$Verfahren;
+und in alb.php in der Funktion ALBAuszug_Flurstueck(...) die Zeilen für die Darstellung der Verfahren an der Stelle # Verfahren ersetzen. Alter Abschnitt:
+ # Verfahren
+ if ($flst->Verfahren['flurstkennz']!='') {
+   $pdf->addText($col0,$row-=24,$fontSize,'Ausführende Stelle');
+   $pdf->addText($col2_1,$row,$fontSize,$flst->Verfahren['ausfstelleid']);
+   $AusfStelleName=zeilenumbruch($flst->Verfahren['ausfstellename'],40);
+   $pdf->addText($col4,$row,$fontSize,$AusfStelleName[0]);
+   for ($j=1;$j<count($AusfStelleName);$j++) {
+     $pdf->addText($col4,$row-=12,$fontSize,$AusfStelleName[$j]);
+   }
+   $pdf->addText($col0,$row-=12,$fontSize,'Verfahren');
+   $pdf->addText($col2_1,$row,$fontSize,$flst->Verfahren['verfnr']);
+   $pdf->addText($col4,$row,$fontSize,'('.$flst->Verfahren['verfbemid'].')');
+   $AusfBemerkung=zeilenumbruch($flst->Verfahren['verfbemerkung'],40);
+   $pdf->addText($col5,$row,$fontSize,$AusfBemerkung[0]);
+   for ($j=1;$j<count($AusfBemerkung);$j++) {
+     $pdf->addText($col5,$row-=12,$fontSize,$AusfBemerkung[$j]);
+   }
+ }
+Neuer Abschnitt:
+ # Verfahren
+ $anzVerfahren=count($flst->Verfahren);
+ for ($i=0;$i<$anzVerfahren;$i++) {
+   $pdf->addText($col0,$row-=24,$fontSize,'Ausführende Stelle');
+   $pdf->addText($col2_1,$row,$fontSize,$flst->Verfahren[$i]['ausfstelleid']);
+   $AusfStelleName=zeilenumbruch($flst->Verfahren[$i]['ausfstellename'],40);
+   $pdf->addText($col4,$row,$fontSize,$AusfStelleName[0]);
+   for ($j=1;$j<count($AusfStelleName);$j++) {
+     $pdf->addText($col4,$row-=12,$fontSize,$AusfStelleName[$j]);
+   }
+   $pdf->addText($col0,$row-=12,$fontSize,'Verfahren');
+   $pdf->addText($col2_1,$row,$fontSize,$flst->Verfahren[$i]['verfnr']);
+   $pdf->addText($col4,$row,$fontSize,'('.$flst->Verfahren[$i]['verfbemid'].')');
+   $AusfBemerkung=zeilenumbruch($flst->Verfahren[$i]['verfbemerkung'],40);
+   $pdf->addText($col5,$row,$fontSize,$AusfBemerkung[0]);
+   for ($j=1;$j<count($AusfBemerkung);$j++) {
+     $pdf->addText($col5,$row-=12,$fontSize,$AusfBemerkung[$j]);
+   }
+ }
+'''Hinweis:'''<br>
+wenn in der config.php die Konstanten:<br>
+'POSTANSCHRIFT', 'POSTANSCHRIFT_STRASSE', 'POSTANSCHRIFT_PLZ', 'POSTANSCHRIFT_ORT'<br>
+mit Werten belegt sind, wird im Ausdruck die Adresse zweimal untereinander ausgegeben. Soll das so sein?
+Für Anwender mit ALB-Daten mehrer Kreise in einer Datenbank wäre es sinnvoll, wenn die Katasteramtsziffer (katasteramt) und die Bezeichnung der Behörde mit Anschrift und Tel.Nr. (name) oben rechts auf dem Ausdruck nicht aus der config.php geholt werden würde sondern aus der tabelle "alb_v_katasteraemter" der Datenbank.
+Zusätzlich sollte im Ausdruck der Stand der ALB-Daten angegeben werden, da es sich um Sekundärdaten handelt. Dieses Datum sollte aus der Tabelle alb_fortführung das letzte Datum der Spalte "ffzeitraum_bis" sein.
+== + Fehler in der Kartendarstellung ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 12:48, 12. Sep 2006 (CEST)
+Wenn zwei User zum selben Zeitpunkt eine Karte erzeugen, erhält der eine das Kartenbild des anderen, obwohl vom Mapserver im tmp-Verzeichnis korrekt zwei Karten abgelegt werden.
+*--[[Benutzer:Rahn|Rahn]] 12:58, 12. Sep 2006 (CEST) Stimmt, das liegt daran, dass die svg-Datei immer gleich heißt und beide User dann auf dieselbe Datei zugreifen. Um den Fehler zu beheben einfach in der SVG_map.php folgende Zeile:
+ $svgfile  = 'SVG_map.svg';
+durch diese beiden hier ersetzen:
+ $randomnumber = rand(0, 1000000);
+ $svgfile  = $randomnumber.'SVG_map.svg';
+== + Notizenverwaltung ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 15:25, 5. Sep 2006 (CEST) Ich habe erstmalig Notizenkategorien in der Notizenverwaltung angelegt. Sie werden auch in der Auswahlliste angezeigt. Beim Auswählen und (automatischen) Neuladen der Seite sind sie dann jedoch nicht ausgewählt?!
+* --[[Benutzer:Pkorduan|Pkorduan]] 15:11, 14. Sep 2006 (CEST) Da hilft erstmal eine Notizkategorie per Hand der Stelle zuzuweisen wenigstens mit Leserechten. Im Formular müssen wir mal schauen, wie wir das anpassen.
+== + Nachweisverwaltung: Problem beim Downloaden von TIFF's ==
+--[[Benutzer:A.tower|Andreas Thurm]] 07:50, 12. Sep 2006 (CEST)Ab der Version 1.6.1 gibt es ein Problem beim Anzeigen und Downloaden von Nachweisen im TIFF-Format. Die Dokumente lassen sich nicht anzeigen. Es erscheint die Fehlermeldung, dass hier ein unbekanntes Dateiformat vorliegt. Kopiert man die Datei mit winscp auf den Client,lässt sie sich problemlos anzeigen. In der Version 1.6.0 funktioniert der Download und die Anzeige noch reibungslos. Andere Dateiformate wie z. Bsp. PDF sind von diesem Problem scheinbar nicht betroffen.
+* --[[Benutzer:Pkorduan|Pkorduan]] 14:07, 14. Sep 2006 (CEST) Das Problem kann folgendermaßen gelößt werden:
+ In der Datei kvwmap.php in der Funktion: nachweisDokumentAnzeigen() vor die Zeile:
+ header("Content-type: image/".$dateinamensteil[1]);
+die Zeile
+ ob_end_clean();
+einfügen. Dadurch wird der vorher ausgegebene Header gelöscht und der richtige gesendet.
+== + Druckmaßstab ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 09:54, 11. Sep 2006 (CEST)
+Die Orthophotos werden bis zu genau 1:5.000 angezeigt (d.h. Eintrag in der Tabelle used_layer = 1:5.001). Wenn ich mit dem Kartenmaßstab in die Druckausschnittswahl gehe, werden die Orthofotos noch angezeigt. Wenn ich dann weiter in die Druckvorschau gehe, werden sie nicht mehr angezeigt - auch nicht im PDF-Dokument. Wenn ich als Druckmaßstab 1:4.999 wähle, werden sie sowohl in der Druckvorschau als auch im PDF angezeigt. Sie müssen jedoch auch bei 1:5.000 im Druck erscheinen.
+*--[[Benutzer:Rahn|Rahn]] 10:15, 11. Sep 2006 (CEST) Damit ein Layer bei uns bis 1:5000 angezeigt wird, muss ich bei max_scale 5000 eintragen und nicht 5001. Und bei einem Druckmaßstab von 1:5000 erscheint dieser Layer dann auch in der Druckvorschau und im PDF. Hmmm, wie ist das zu erklären?
+== + Sachdatenabfrage ==
+--[[Benutzer:Pkorduan|Pkorduan]] 11:03, 19. Sep 2006 (CEST) Ein weiteres Problem war, dass die OGR Layer nicht abfragbar waren.
+Dazu wurde jetzt in der Datei kvwmap.php in der Funktion SachdatenAnzeige($rect) folgendes hinzugefügt. Hinter den Zeilen:
+ # Abfrage von Shapelayern
+ $layer=ms_newLayerObj($map);
+ $layer->set('data', $layerset[$i]['Data']);
+folgene zusätzliche einfügen:
+ $layer->set('connectiontype',$layerset[$i]['connectiontype']);
+ $layer->set('connection', $layerset[$i]['connection']);
+ $layer->set('type',$layerset[$i]['Datentyp']);
+--[[Benutzer:Pkorduan|Pkorduan]] 14:01, 4. Sep 2006 (CEST) Die Sachdatenanfrage liefert einen Fehler, wenn die SRID der Rolle ein andere ist als die des Layers. Eine Sachdatenabfrage auf einer Tabelle mit Fachdaten in der Postgis-DB mit der Version 1.6.1 erzeugt folgende Fehlermeldung:
+<pre>
+Warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error at or near ")" at character 244 in /usr/local/httpd-2.2.3/htdocs/kvwmap-1.6.1/class/postgresql.php on line 3332
+</pre>
+Es liegt an einem Fehler im Quellcode. In der Funktion SachdatenAnzeige() in der Datei kvwmap.php ist in der Zeile
+<pre>
+$sql_where =" AND the_geom &&
+Transform(GeomFromText('".$searchbox_wkt."',".$client_epsg."),".$layer_epsg."))";
+</pre>
+hinten ein ")" zuviel.
+== -+ WLDGE2SQL Fehler ==
+--[[Benutzer:Pkorduan|Pkorduan]] 14:05, 4. Sep 2006 (CEST) Beim Einlesen der WLDGE-Dateien fehlen die Buchungsarten. Der Fehler tritt schon seit 1.6.0 auf, ist aber jetzt erst bemerkt worden.
+Grund: Bei der Umstellung des SQL-Statement zur Berücksichtung von mehrfachen Buchungen wurde die Buchungsart versehentlich vergessen. Zur Behebung des Problems folgenden Bugfix durchführen.
+Bugfix 2006-09-06 pk:
+Datei: postgresql.php
+Funktion: insertGrundstueck
+Zeile:<pre>
+    $sql.="SELECT '".$Bezirk."','".$Blatt."','".$BVNR."'";
+</pre>
+ersetzen durch:
+<pre>
+    $sql.="SELECT '".$Bezirk."','".$Blatt."','".$BVNR."','".$Buchungsart."'";
+</pre>
+== + Suche nach Grundbuchblattnummern ==
+--[[Benutzer:A.tower|Andreas Thurm]] 15:53, 7. Sep 2006 (CEST) Innerhalb der Namensuche ist es jetzt möglich nach Grundbuchblattnummern zu suchen. Diese Suche bringt bei mir als Ergebnis immer die Meldung, dass keine Namen gefunden werden konnten, egal ob die Grundbuchblätter existieren oder nicht.
+:--[[Benutzer:Markus Hentschel|Markus Hentschel]] 08:29, 12. Sep 2006 (CEST) Diese Meldung bekomme ich dann, wenn ich die Grundbuchblattnummer nicht mit führenden Nullen angebe, also z.B. "1234" statt "01234". Das ist unschön, denn wer will schon immer diese ganzen Nullen vorneweg schreiben? Das könnte irgendwie abgefangen werden. Leider helfen hier auch keine Platzhalter, "%1234" funktioniert nicht.
+:--[[Benutzer:Pkorduan|Pkorduan]] 15:20, 14. Sep 2006 (CEST) Markus, das kann so nicht ganz stimmen. Wenn Du keine Führenden Nullen eingibst, müsste eigentlich gesagt werden, dass man einen Fehler gemacht hat und 5-stellige Nummern eingeben soll. Exakt: "Angaben fehlerhaft: Die Blattnummer ist keine 5 Zeichen lang."
+Also Andreas noch mal genau beschreiben was Du eingibst, mit oder ohne Nullen. Ohne Nullen und Fehler: "Es konnten keine Flurstücke zu dem Grundbuchblatt gefunden werden" kann nur kommen wenn Blattnummer auch wirklich 5 stellig sind, ansonsten sind die Blätter nicht da. Da müssen wir uns noch mal die SQL-Statements ansehen, die abgesetzt werden und in Postgres Client testen.
+Unabhängig davon könnte ich auch Suche ohne führende Nullen einrichten. Dann bitte auf die ToDo. Dürfte recht schnell gehn.
+::--[[Benutzer:Markus Hentschel|Markus Hentschel]] 10:14, 15. Sep 2006 (CEST) Wenn ich nach Bezirk "132427" und Blatt "00008" suche, kriege ich 1 Treffer. Wenn ich nach Bezirk "132427" und Blatt "8" suche, kriege ich die Meldung "Es konnten keine Namen gefunden werden, bitte ändern Sie die Anfrage!" Ich setzt die Suche ohne führende Nullen auf die ToDo, wenn niemand was dagegen hat.
+= Version 1.6.0 =
+== Anzeige der Zeichenreihenfolge ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:55, 1. Sep 2006 (CEST)
+Die Anzeige der Zeichenreihenfolge der Layer in der Stellenanzeige zeigt nur 4 Stellen an. Nötig wäre die Anzeige von mindestens 6 Stellen, besser 7.
+== Festpunkte in KVZ schreiben ==
+--[[Benutzer:HolgerR|HolgerR]] 17:11, 7. Aug 2006 (CEST)
+Beim Erstellen des KVZ wird bei den Punkten, die eine Höhenangabe besitzen ein Leerzeichen zwischen Hochwert und Höhe zuviel ausgegeben.
+Kurzfristige Hilfe schafft das Editieren der Datei katasetr.php Zeile 128 wie folgt:
+<pre>
+ $zeile.=sprintf("%08.3f",$p["hoe"]); # 48-55 Höhe
+</pre>
+statt
+<pre>
+ $zeile.=" ".sprintf("%08.3f",$p["hoe"]); # 48-55 Höhe
+</pre>
+== Namenssuche ==
+--SigridP 09:29, 28. Jul 2006 (CEST)
+Bei Eingabe eines Namens kommt die Fehlermeldung:<br>
+Es konnten keine Namen gefunden werden, bitte ändern Sie die Anfrage!<br>
+Warning: Missing argument 10 for getnamen() in /srv/www/htdocs/kvwmap-1.6.0/class/postgresql.php on line 1713
+== Druckrahmenverwaltung ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 12:03, 18. Jul 2006 (CEST)
+Der Freitext wird nicht dahin geschrieben, wo er in der Druckrahmenverwaltung (und auch noch in der Vorschau) positioniert wird, sondern zu weit unten und zu weit rechts.
+== Filterverwaltung ==
+--[[Benutzer:Rahn|Rahn]] 13:31, 27. Jul 2006 (CEST)
+Bei Benutzung der Filterverwaltung kann es auch zu einem Fehler kommen, wenn die MySQL-DB älter als Version 4.1.0 ist. Dann lassen sich nämlich keine erstellten Filter abspeichern. Deswegen also am besten eine neuere Version verwenden.
+--[[Benutzer:Rahn|Rahn]] 14:33, 18. Jul 2006 (CEST)
+Wählt man in der Filterverwaltung einen Layer aus, kann es sein, dass die Attribute nicht geladen werden können und es zu einer Fehlermeldung kommt. Um den Fehler zu beheben, muss man die Funktion '''getDataAttributes''' in '''kvwmap.php''' durch diese hier ersetzen:
+ function getDataAttributes($database, $layer_id){
+   $sql ='SELECT Data FROM layer WHERE Layer_ID = '.$layer_id;
+   $this->debug->write("file:kvwmap class:db_mapObj->getDataAttributes - Lesen der Attribute aus Data:".$sql,4);
+   $query=mysql_query($sql);
+   if ($query==0) { $this->debug->write("Abbruch Zeile: ".__LINE__,4); return 0; }
+   $rs = mysql_fetch_array($query);
+   $data = $rs[0];
+   if($data != ""){
+    	if(strpos($data, '(') === false){
+    		$from = stristr($data, 'from');
+    		$fooposition = strpos($from, 'as foo');
+    		if($fooposition > 0){
+    			$from = substr($from, 0, $fooposition);
+    		}
+    		$select = 'select * '.$from;
+    	}
+    	else{
+              $select = stristr($data,'(');
+              $select = trim($select, '(');
+              $select = substr($select, 0, strrpos($select, ')'));
+    	}
+      $attribute = $database->getFieldsfromSelect($select);
+      return $attribute;
+    }
+   else{
+     echo 'Das Data-Feld des Layers mit der Layer-ID '.$layer_id.' ist leer.';
+     return NULL;
+   }
+ }
+== config.php ==
+Ist zwar kein richtiger Bug, da wir aber gesagt haben alle Neuerungen in der config.php mit der Versionsnummer zu kennzeichnen, hier der Hinweis:
+Es gibt zwei Zeilen, bei denen vergessen wurde, diese zu kennzeichnen:
+ include (CLASSPATH.'spatial_processor.php');
+ define("WFS_SRS","EPSG:25833");
+== Sachdatenanzeige Flurstücke ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:45, 14. Jul 2006 (CEST)
+In der flurstuecke.php und der flurstuecksanzeige.php ist das ALB-Format 40 (Eigentümeranzeige) nicht an Rechte gebunden. Es müsste aber genauso laufen wie beim Format 35, dass nämlich das Recht zur Ansicht abgefragt wird.
+== Adresssuche ==
+--[[Benutzer:Markus Hentschel|Markus Hentschel]] 13:42, 14. Jul 2006 (CEST)
+Nach der Auswahl der Gemeinde werden die Straßen ausgewählt. Die erste Straße der Liste steht bereits im Fenster. Allerdings kann man zu dieser ersten Straße keine Hausnummer auswählen. Man muss zuerst eine andere Straße aufrufen und dann anschließend nochmal die erste Straße.<br>
+--[[Benutzer:Heinz Schmidt|Heinz Schmidt]] 15:22, 17. Jul 2006 (CEST)<br>
+Ist bei mir in der Version 1.5.9 auch schon so, war mir aber noch nicht aufgefallen.
+== Informationsabfrage ==
+--[[Benutzer:Heinz Schmidt|Heinz Schmidt]] 07:16, 12. Jul 2006 (CEST)
+=== Fehlermeldung "Keine Bearbeitung moeglich! ..." ===
+Nach Aufziehen eines Rechtecks erscheint ein blaues Popup-Fenster mit der Meldung:<br>
+"Keine bearbeitung möglich! Uebergebene Daten: ppquery_box, ###,###"<br>
+Hingegen arbeitet die punktuelle Informationsabfrage ohne Probleme.
+Problemlösung von Stefan Rahn:
+um den Fehler zu beheben, in der Datei SVG_map.php die Funktion sendpath
+durch folgenden Code ersetzen:
+ function sendpath(cmd,pathx,pathy)   {
+    path  = "";
+    switch(cmd)
+    {
+     case "zoomin_point":
+      path = pathx[0]+","+pathy[0];
+      document.GUI.INPUT_COORD.value  = path;
+      document.GUI.CMD.value          = "zoomin";
+      document.GUI.submit();
+     break;
+     case "zoomout":
+      path = pathx[0]+","+pathy[0];
+      document.GUI.INPUT_COORD.value  = path;
+      document.GUI.CMD.value          = cmd;
+      document.GUI.submit();
+     break;
+     case "zoomin_box":
+      path = pathx[0]+","+pathy[0]+";"+pathx[2]+","+pathy[2];
+      document.GUI.INPUT_COORD.value  = path;
+      document.GUI.CMD.value          = "zoomin";
+      document.GUI.submit();
+     break;
+     case "recentre":
+      path = pathx[0]+","+pathy[0];
+      document.GUI.INPUT_COORD.value  = path;
+      document.GUI.CMD.value          = cmd;
+      document.GUI.submit();
+     break;
+     case "pquery_point":
+      path = pathx[0]+","+pathy[0]+";"+pathx[0]+","+pathy[0];
+      document.GUI.INPUT_COORD.value  = path;
+      document.GUI.CMD.value          = "pquery";
+      document.GUI.submit();
+     break;
+     case "pquery_box":
+      path = pathx[0]+","+pathy[0]+";"+pathx[2]+","+pathy[2];
+      document.GUI.INPUT_COORD.value  = path;
+      document.GUI.CMD.value          = "pquery";
+      document.GUI.submit();
+     break;
+     case "ppquery_point":
+      top.document.GUI.searchradius.value = "";
+      path = pathx[0]+","+pathy[0]+";"+pathx[0]+","+pathy[0];
+      document.GUI.INPUT_COORD.value  = path;
+      document.GUI.CMD.value          = "ppquery";
+      document.GUI.submit();
+     break;
+     case "ppquery_box":
+      top.document.GUI.searchradius.value = "";
+      path = pathx[0]+","+pathy[0]+";"+pathx[2]+","+pathy[2];
+      document.GUI.INPUT_COORD.value  = path;
+      document.GUI.CMD.value          = "ppquery";
+      document.GUI.submit();
+     break;
+     case "pquery_polygon":
+      path = pathx[0]+","+pathy[0]+";"+pathx[2]+","+pathy[2];
+      document.GUI.INPUT_COORD.value  = path;
+      document.GUI.CMD.value          = "pquery";
+      document.GUI.submit();
+     break;
+     default:
+      path = pathx[0]+","+pathy[0];
+      alert("Keine Bearbeitung moeglich! \nUebergebene Daten: "+cmd+", "+path);
+     break;
+    }
+  }
+== Stelleneditor - Stelle ändern ==
+--[[Benutzer:HolgerR|HolgerR]] 13:48, 21. Aug 2006 (CEST)
+Beim Auswählen einer Stelle und 'Als neue Stelle eintragen' sind die Eintragungen zum Layer verschwunden. In der Debug-Datei erscheint folgender Eintrag :
+<pre>
+file:users.php class:stelle->copyLayerfromStelle - kopieren der Layer von einer Stelle:
+INSERT IGNORE INTO used_layer ( `Stelle_ID` , `Layer_ID` , `queryable` , `drawingorder` , `minscale` , `maxscale` ,
+ `offsite` , `Filter` , `template` , `header` , `footer` , `symbolscale`, `logconsume`, `requires` )
+SELECT 62, `Layer_ID` , `queryable` , `drawingorder` , `minscale` , `maxscale` , `offsite` , `Filter` , `template` ,
+ `header` , `footer` , `symbolscale`, `logconsume`, `requires`
+FROM used_layer WHERE Stelle_ID = 8 AND Layer_ID = 1
+Abbruch in Zeile: 1860
+</pre>
+Bei mir in der Datenbank fehlt die Spalte 'offsite'. In der 'mysql_update.sql' ist dieser Eintrag zur Tabelle 'used_layer' nicht zu finden.
+Die Spalte 'offsite' kann mit folgender SQL-Anweisung eingefügt werden:
+<pre>
+ALTER TABLE used_layer
+ADD offsite varchar(11) default NULL;
+</pre>
+Was wird mit der Spalte 'offsite' bei der Darstellung der Layer bewirkt?
+Bei der weiteren Betrachtung des Quellcodes ist mir aufgefallen, dass in den Funktionen 'addLayer' und 'updateLayer' die Anweisungen zur Übernahme/Aktualisierung der Daten aus der Spalte 'requires' fehlen.
+== Stelleneditor - Menuezuordnung ==
+--[[Benutzer:HolgerR|HolgerR]] 14:22, 21. Aug 2006 (CEST)
+Ich habe den Effekt, dass bei jedem Ändern der Stelle, sich die Anzahl der Menueeinträge um die ursprüngliche Anzahl der zugeordneten Menues erhöht.
+Gibt es eine schnelle Abhilfe?
 = Version 1.5.9 =

Ältere Versionen: Unterschied zwischen den Versionen

Version vom 23. Dezember 2009, 09:29 Uhr

Inhaltsverzeichnis

Version 1.6.9

+ Spaltenbreite für 'symbolname' in Tablle 'styles' zu gering

+ Keine Möglichkeit 'minwidth' und 'maxwidth' in die Tabelle 'styles' einzugeben

+ Übergabe des Feldnames aus 'angleitem' an Mapdatei erfolgt nicht

+ Darstellung von CARTOLINE funktioniert nicht

+ Kartenausschnitt nach Layersuche

+ Ausrichtung Nordpfeil

+ Flurstücksdatenanzeige| Aktualität der ALK-Daten

- labelangleitem unter Mapserver 5.0.2

- PostgreSQL 8.3.x - WHERE mit unterschiedlichen Datentypen

+ Generischer Layereditor - Geometrie hinzufügen ohne Geometrie

- Generischer Layereditor - Geometrie hinzufügen - Fehler bei 'ORDER BY - Klausel' in Data

+ Tabelle u_menues Spalte order

+ Fehlermeldung wenn ein Nutzer keiner Stelle zugeordnet ist

+- Einfärbung gesuchter Objekte

+ Firefox 3 - Werkzeugleiste

+ Antraganzeige - Zugeordnete Festpunkte in KVZ Schreiben

+ Dokumentenrecherche über Individuelle Nummer oder Antragsnummer :-(

+ Notizen erstellen

- vorherige Ansicht / naechste Ansicht im Kartenfenster

+ Dokumentenrecherche über Polygon

+ GLE | nachträgliches Erfassen von Punktgeometrien

- Filterverwaltung

Version 1.6.8

+ Hausnummernsortierung in Adresssuche

+ Suchergebnis nach Flurstückssuche

+ auseinandergezogene Menüs

+ Laufzeitfehlermeldung bei Koordinatenzoom

+ Mittelpunkt setzen mit Pan geht nur einmal

+ CSV-Export Flurstücke

+ Geometrie-Editor - Geometrieübernahme

+ Fehlermeldung bei Login-Fehler

+ Nachweisverwaltung - Rechercheergebnis - Nachweise Löschen

+ Festpunkte Sachdatenanzeige - kein Sprung auf Punkt

+ Flächenmessung/Streckenmessung im IE

+ Druckvorschau | Fehlermeldung

+ Grundbuchblattsuche | Flurstücksdaten anzeigen

+ Stelle Wählen

+ Druckausschnitt wählen - Zoom

- Referenzkarte im Druck bei Nicht-Standard-SRS

+ Kartenbild anzeigen

- ALB-Einlesen - keine Auswertung der Kopfzeile

+ Zuweisen von Untermenüpunkten im InternetExplorer

+ Löschen von Stellen

+ Beim Speichern neuer Stellen passiert auch nichts

+ Beim Speichern neuer Layer passiert nichts

+ Fehler bei der Grundbuchblattanzeige von der Namenssuche aus

+ Benutzer anlegen und bearbeiten

Version 1.6.7

+ postgis_install.sql - fp_punkte2 - gist

- Anzeige der Flurstücke bei der Namenssuche

+ Gemarkungsauswahl bei der Namenssuche

- Bugs in der Nachweiserfassung

+ Lagebezeichnung im ALB-Ausdruck

+ Time-Attribut bei Geometrieänderung

+ Flächenanzeige im Polygoneditor

+ Platzhalter in der Namenssuche

+ weitere Treffer anzeigen nach CSV-Export

+ Fehler beim Anzeigen von ALB-Auszügen für alle Flurstücke

+ Fehler in der Nachweisrecherche und im Punkteditor

- Namenssuche | Suchen mit Entertaste

+ Adressänderungstabelle bereinigen

Version 1.6.6

- Fehler in Notizkategorienverwaltung

+ Feld Wert in der Filterverwaltung muss Typ 'text' sein

+ als neuer Druckrahmen speichern | Ref.-Mapfile

+ OID in Hochkomma

+ Nachweiserfassung/-recherche | Länge von Stammnummer und Blattnummer

- Gemarkungsauswahl in der Namenssuche

+ Notizen | Fehlermeldung Notizenformular

- Stellenverwaltung | Stelle kopieren

+ Shape-Export

- Generischer Layereditor (GLE)

- Lagebezeichnung im ALB-Ausdruck

+ Layernamen mit Sonderzeichen im Shape-Export

+ Anzeige der Namensnummern im ALB-Auszug 35

+ Nachweise mit alphanumerischer Blattnummer anzeigen