<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hallo Frank,<br>
<br>
vielen Dank für deine Anpassungen. Es hört sich sehr sinnvoll an,
die Auskunfts- und Suchskripte auf die norGIS-ALKIS
Struktur anzupassen und somit das Post-Processing
zu umgehen. Dein Einsatz am Rosenmontag ist natürlich sehr
lobenswert. Bei uns im Rheinland wurden an dem Tag wohl eher
Kamelle gefangen und gelutscht.<br>
<br>
Die neuen Skripte unter navn/ werde ich demnächst einmal testen.
Sicherlich ist es sinnvoll auch die "Buchauskunft" und die
Mapfiles (WMS)
umzuziehen.<br>
<br>
Vielleicht könnten auch die Kommentare zu den Tabellen der
norGIS-ALKIS
Struktur gesetzt werden. Die Kommentare erhöhen die
Übersichtlichkeit schon enorm.<br>
<br>
Das Osterei habe ich übrigens gefunden ;)<br>
<br>
Schönen Gruß<br>
<br>
Astrid Emde<br>
<br>
<br>
Am 11.02.2016 18:33, schrieb Jäger, Frank (KRZ):<br>
</div>
<blockquote
cite="mid:F2176AE4E9FFAF45BEA8D84DD6F4AF1A1E445D62@skrzmxmbx01"
type="cite">
<pre wrap="">Hallo Freunde von PostNAS,
noch ist die Republik geteilt:
- Wer das "klassische" Web-GIS mit Mapbender und PHP/HTML-Auskunft und Mapfile verwendet, der konvertiert per Shellscript und dem darin eingebauten Post-Processing, das Hilfstabellen aufbaut für Mapserver-WMS und PHP-Scripte.
- Wer die ALKIS-Karte lieber im QGIS-Client betrachtet, der konvertiert mit dem norGIS-ALKIS-Importer. Dort findet auch ein Post-Processing statt, aber ein anderes.
Der Riss geht mitten durch unser Rechenzentrum: Ich konvertiere die NBA-Daten der Gemeinden für meine Web-GIS-Kunden.
Meine Kollegen konvertieren das noch mal für die NorGIS/QGIS-Kunden, viele davon sind identisch.
Wenn der Tag mehr als 24 Stunden hätte, dann hätte ich längst etwas unternommen, um diesen Zustand zu verbessern. Aber es gibt immer sooo viel andere dringende Arbeiten.
Seit Montag - ja am Rosenmontag wird hier GEARBEITET - habe ich nun zunächst mal begonnen, die PHP-Scripte für die Mapbender-Suche (Navigation) so umzustellen, dass sie mit der Datenbank-Struktur funktionieren, wie sie aus dem norGIS-ALKIS-Importer kommt.
Diese neuen Programmversionen (4 Module) habe ich vorläufig hochgeladen in den Ordner <a class="moz-txt-link-freetext" href="http://trac.wheregroup.com/PostNAS/browser/trunk/mapbender/http/navn/">http://trac.wheregroup.com/PostNAS/browser/trunk/mapbender/http/navn/</a>
Diese Programmversionen können die Versionen in ../nav/ ersetzen. Der Rest im Ordner ist identisch.
Diese Versionen funktionieren NICHT mit der klassischen Datenbank-Struktur. Die Konfiguration muss also auf eine NorGIS-ALKIS-DB zeigen.
Das taugt also derzeit nur für eine Testumgebung, in der man für ein Gebiet zwei synchrone Datenbankversionen hat. Denn die Navigation verlinkt ja zur Auskunft, die noch nicht umgestellt ist.
Bei den Arbeiten habe ich festgestellt, dass es einige Format-Unterschiede im Datenbank-Schema gibt, auch bei den Stammtabellen (ax_*), nicht nur bei den Hilfstabellen aus dem Post-Processing. So sind z.B. "zaehler" und "nenner" bei den historischen Flurstücken Character-Strings, die linksbündig ohne führende Nullen gefüllt sind. Das erschwert die Sortierung, die der Anwender "numerisch" erwartet.
Die Tabellen "pp_gemarkung" und "pp_gemeinde" wurden in den Scripten intensiv genutzt, weil darin die Relation "Gemeinde-Gemarkung" enthalten ist, die merkwürdigerweise in "ax_gemarkung" nicht enthalten ist. Weiß jemand warum das so ist? Gibt es Bundesländer wo eine Gemarkung nicht Teil einer Gemeinde ist?
Einen Ersatz habe ich in den Tabellen "gem_shl" und "gema_shl " gefunden. Die Formatierung der Spalten in langen mit Leerzeichen aufgefüllten Feldern macht aber den ständigen Gebrauch von Substring- und Trim-Funktionen notwendig. Vielleicht kann das zukünftig noch optimiert werden.
Mangels Kommentaren in der Datenbank weiß ich nicht, wozu diese Tabellen ursprünglich aufgebaut wurden.
Für die PP-Tabelle "gemeinde_person" habe ich keinen Ersatz gefunden. Diese Tabelle verdichtet die lange Relation
"Person-Namensnummer-Grundbuch-Buchung-Flurstück-Gemeinde" (und die Sonderfälle Recht Buchung-an-Buchung) auf die beiden Enden.
Damit kann ich bei der Suche nach Personen-Namen gleich den Gemeinde-Filter anwenden. Das verhindert, dass man in Sackgassen hinein sucht.
Man findet sonst Name, Grundbuch und Buchung, ist aber am Ende nicht berechtigt, das darauf gebuchte Flurstück zu sehen, weil es in einer fremden Gemeinde liegt. Dies kommt bei uns nicht vor, weil jede Gemeinde ihren einen NBA hat. Ich habe aber auch an andere Konstellationen gedacht. Wenn z.B. mehrere Gemeinde-GUIs an einer kreisweiten Datenbank hängen, dann kann dies Filter-Problem auftauchen.
Vielleicht kann eine entsprechende Tabelle mal in den NorGIS-Importer übernommen werden.
In Kommentarzeilen im Programm weise ich auf diese Probleme hin.
Wer mag, kann die Programme testen und mir Fehlerhinweise schicken. Die laufen hier noch nicht in Produktion.
Hinweis: Beim Einbinden von gazetteer_alkis in die Mapbender-GUI in der URL die Gemeinde-Nummer nun immer 3stellig angeben. Auch eine Folge von unterschiedlichen Spalten-Formaten.
Jetzt muss ich "nur noch" die "Buchauskunft" und die Mapfiles (WMS) umstellen, dann brauchen wir nicht mehr doppelt konvertieren.
Dann wird z.B. auch das "alte" DB-Schema nicht mehr benötigt. Bevor das verschwindet: Hat eigentlich mal jemand das "Osterei" gefunden, das ich vor Jahren darin versteckt habe? Schaut in eurer Datenbank mal den Kommentar zur Tabelle "ax_baublock" an ;-)
Mit freundlichen Grüßen
Frank Jäger
Kommunales Rechenzentrum
Minden-Ravensberg/Lippe
Tel.: 05261 / 252 - 185
<a class="moz-txt-link-freetext" href="mailto:f.jaeger@krz.de">mailto:f.jaeger@krz.de</a>
<a class="moz-txt-link-freetext" href="http://www.krz.de/">http://www.krz.de/</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
NAS mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NAS@lists.osgeo.org">NAS@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/nas">http://lists.osgeo.org/mailman/listinfo/nas</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Mit freundlichen Grüßen
Astrid Emde
GIS-Consultant
-----------------------------------
Aufwind durch Wissen!
Qualifizierte OpenSource-Schulungen
bei der <a class="moz-txt-link-abbreviated" href="http://www.foss-academy.eu">www.foss-academy.eu</a>
-----------------------------------
Astrid Emde
WhereGroup GmbH & Co.KG
Eifelstraße 7
53119 Bonn
Germany
Fon: +49(0)228 90 90 38 - 19
Fax: +49(0)228 90 90 38 - 11
<a class="moz-txt-link-abbreviated" href="mailto:astrid.emde@wheregroup.com">astrid.emde@wheregroup.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.wheregroup.com">www.wheregroup.com</a>
Folgen Sie der WhereGroup auf twitter: <a class="moz-txt-link-freetext" href="http://twitter.com/WhereGroup_com">http://twitter.com/WhereGroup_com</a>
Amtsgericht Bonn, HRA 6788
-------------------------------
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Olaf Knopp, Peter Stamm
-------------------------------
pgp-public key:
<a class="moz-txt-link-freetext" href="http://pgp.mit.edu:11371/pks/lookup?search=0x06DA52D72D515284">http://pgp.mit.edu:11371/pks/lookup?search=0x06DA52D72D515284</a>
Signierte und/oder verschlüsselte Nachrichten sind sehr willkommen
Signed and/or encrypted mail is highly appreciated</pre>
</body>
</html>