FAQ (Häufig gestellte Fragen)
-
In welcher Hinsicht kann ich das Formular, die Tabellenausgabe bzw. die Karte an die visuelle Gestaltung meiner Website anpassen?
-
In jeder! Und das auch noch besonders einfach. Wenn Sie bereits eine CSS-Datei haben, die die Stilvorlagen für Ihre Website enthält, brauchen Sie nur eine Zeile zu ändern. Ansonsten ist die Erstellung einer solchen ebenfalls recht schnell erledigt. Alle Ausgaben sind valides xhtml. Die Farben und Größe der Karten sind über die
config.php änderbar.
-
Kann ich die im Paket enthaltene Version der OpenGeoDB durch eine andere (aktuellere) Version austauschen?
-
Ja, eine die OpenGeoDB lässt sich unabhängig von OpenGeoNearestNeighbours aktualisieren: aktuelle Version. Dort wird auch eine monatlich aktualisierte Datei mit allen Änderungen seit dem letzten Komplettbestand angeboten („Delta File“, changes.sql).
-
Wie werden die Karten erstellt? Kann man den Ausschnitt oder den Kartenbestand ändern?
-
Ja. Die Karten werden aus sogenannten e00-Files generiert. Eine schöne Quelle für e00 Files ist der DCW. Hier können Sie Ihre eigenen e00 Dateien generieren und auch noch weitere Elemente wie Flüsse, Städte, und Flächen einblenden. Der Ausschnitt ist per Geokoordinaten bestimmbar, für die Länder Deutschland, Österreich und die Schweiz gibt es Voreinstellungen.
-
Meine Installation meldet einen Fehler, weil die Zeile
require_once('DB.php') nicht richtig ausgeführt werden kann. Die Datei DB.php kann nicht gefunden werden. Allerdings habe ich diese Datei nun in einem im Ordner sources gefunden. Soll ich den Pfad des include-Befehls ändern?
-
Nein, den Pfad bitte nicht ändern! Es handelt sich nämlich nicht um die gleiche Datei. Ihr Problem ist vielmehr, dass Sie die PEAR::DB Module nicht richtig installiert haben (siehe Voraussetzungen). Die Datei, die eingebunden werden soll, stammt aus dem PEAR-Paket und sollte in Ihrem php-Include Ordner liegen. Die Datei
/webapp/Geo/sources/DB.php hingegen stammt aus den OpenGeoPHP-Klassen des OpenGeoDB-Projektes, wo auch ihre Benennung entstand.
-
Warum dauert der erste Aufruf nach dem Ändern / Neueinspielen der DB-Tabelle 'Filialen' länger?
-
Einfach ausgedrückt: Das einmal langsam geschaffene Objekt wird bei weiteren Aufrufen einfach „von der Platte (DB) geladen“.
Genauer ausgedrückt: Um die Entfernung zu berechnen, muss auf Basis der PLZ für jede Filiale ein GeoObject initialisiert werden. Diese Objekt enthält Daten über die geographische Position der Filiale.
Diese Initialisierung dauert jedoch etwas länger (bei mir etwa 1 Sekunde pro Filiale), was durch die Komplexität der SQL-Anfrage bedingt wird. Um zu verhindern, dass diese Initialisierung bei jedem Aufruf abläuft, wurde eine Funktion implementiert, die die GeoObjects serialisiert und in ein blob-Feld der Tabelle 'Filialen' schreibt. Dieser Vorgang wird im Debugger-Modus auch angezeigt. Von hier aus wird das Objekt bei jedem Gebrauch deserialisiert, und steht somit bei jeder Abfrage ohne die Verzögerung wieder zur Verfügung.
-
Nachdem ich in der Tabelle 'Filialen' einen neuen Eintrag hinzugefügt habe, gibt die Beispielanwendung nur noch einen Fehler (
Could not instanciate Geo_Object for PLZ) aus. Why oh why?
-
Ausschlaggebend für die Ortsbestimmung einer Filiale (= Instanziierung des GeoObjects) ist einzig und allein die PLZ der Filiale. Sie können bei Straße und Ort jeden Quatsch eingeben, nur die PLZ muss stimmen, d.h. existieren und in der OpenGeoDB vorkommen. (Wenn Sie eine PLZ kennen, die die Post verwendet, aber nicht in der OpenGeoDB gelistet ist, können Sie diese PLZ direkt in die OpenGeoDB eintragen oder korrigieren.) Wichtig: nachdem Sie eine PLZ eingegeben haben, mit der OpenGeoNearestNeighbours nicht zurecht kommt, müssen Sie unbedingt manuell in der Tabelle Filialen das blob-Feld der entsprechenden Filiale löschen (=frei machen), nur so können Sie die Erzeugung eines neuen GeoObjects erzwingen.
