Bug kvwmap

Auf dieser Seite können Bugs gemeldet werden. Die Lösung von kritischen Fehlern wird beschrieben, so dass eigenständig Bugfixe vorgenommen werden können. Ansonsten finden sich die Lösungen immer in der nächsten Version. Parallel zu dieser Seite werden Bugs und insbesondere deren Lösung auch über die Mailling Liste verteilt. Dies ist mehr ein Archiv der aufgetretenen Probleme. Bugs, die neu sind sollten mit einem führenden - versehen sein. Bugs mit Lösungen werden mit + gekennzeichnet. Problem erkannt und in Arbeit mit -+.

Version 1.6.7

+ 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)

<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.
• --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)

1. Beim Wechsel einer Stelle wird der Extent der Karte aus der aktuellen Stelle für die neue Stelle übernommen.
2. 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?