Tile Updater
Diese Beschreibung gilt nur für den neuen Tile Updater ab Version 24.1.188 . Die Beschreibung des alte TileUpdaters (Mum.Geo.TileUpdate.exe) finden Sie hier https://help.mapedit.de/admin-guide/mapedit-tools/tile-updater/
Der Tile Updater kann für Oracle, Postgres und SQLite Datenbanken verwendet werden. SQLite Datenbanken sind im Allgemeinen immer eine schlechte Alternative. Da diese keine zeitgleichen Zugriffe erlauben, verwenden Sie als alternative immer besser Postgres (OpenSource).
Es werden nur MapEdit und AutoCAD Map3D Datenstrukturen unterstützt.
Für Postgres muss zwingend mindestens Version 24.1.188 bzw. 24.2.3 genutzt werden!
Vorab Test-Versionen kleiner 24.1.188 sind funktional nicht fehlerfrei nutzbar!
Was macht der Tile Updater?
Für eine schnelle Performance der Karte können in MapEdit vorgerenderte Kacheln und auch Live-gerenderte Kacheln verwendet werden. Beide Kacheln werden fest in die Verzeichnisse auf dem Server gespeichert.
Der Inhalt der Kacheln ist nur zum Zeitpunkt des Erzeugens der Kacheln richtig. Werden Daten hinterher geändert stimmen ggf. Kacheln nicht mehr und müssen aktualisiert werden.
Es gibt zwei Möglichkeiten die Kacheln auf den neusten Stand zu bringen:
Die einfachste Möglichkeit ist, z.B. jede Woche (oder täglich) alle Kacheln zu löschen und dann wieder erzeugen zu lassen.
Nehmen wir an, Sie haben nur eine kleine Linie neu gezeichnet, dann müssen Sie bei diesem Verfahren trotzdem alle Kacheln neu erzeugen, obwohl vielleicht nur eine Kacheln betroffen ist.
Eine besser Möglichkeit bietet der Tile Updater!
Der Tile Updater untersucht, ob Änderungen in der Datenbank geschehen sind und erzeugt nur diejenigen Kacheln neu, die von der Änderung betroffen sind. Dadurch wird vermieden, dass bei einer Datenänderung alle Kacheln neu erzeugt werden müssen. Ist die TileServer Konfiguration nur auf Liverendern definiert, dann löscht der Tile Updater nur "alte" Kacheln und erstellt keine neuen – das Erstellen von neuen Kacheln wird nur bei Zoomstufen automatisch angestoßen.
Der Tile Updater versucht gezielt nur die Kachelbereiche zu löschen, in denen auch Änderungen vorgenommen wurden, um dann nur die wenigen benötigten Kacheln neu zu erzeugen.
Der Tile Updater installiert dazu Datenbank-Trigger auf alle Tabellen.
Sobald ein Datensatz geändert, neu erzeugt oder gelöscht wird, registriert der Trigger diese
Änderungen in einer Hilfstabelle ME_TILEUPDATER_LOG.
Änderungen an Views werden je nach Konfiguration in der Hilfstabelle ME_TILEUPDATER_DIFF geloggt.
Bei SQLite Datenbanken werden keine Trigger verwendet.
Wenn nun der Tile Updater, z.B. nächtlich oder wöchentlich ausgeführt wird, werden nur die betroffenen Kacheln neu erzeugt und nicht alle Kacheln.
Bedenken Sie, dass nicht nur Änderungen in der Geometrie den Inhalt einer Kacheln verändern können. Z.B. kann die Farbe einer Linie abhängig von einem Attribut eines Datensatzes dargestellt werden. Oder der Text eines Anschriebs (Labels) hat sich geändert.
Wenn Sie nur wenige Kacheln und kleine Datenmengen haben oder die Kacheln nur alle paar Monate aktualisieren wollen, ist das komplette Neukacheln ohne Nutzung des Tile Updaters der einfachere und weniger Fehleranfällige weg.
Ein anderer einfacher Weg ohne Nutzung des TileUpdaters ist die Option "tilerefreshperiod" im TileServer
zu nutzen:
https://help.mapedit.de/admin-guide/mapedit-tileserver/tileserver_conf#tilerefreshperiod
Mit dieser Option kann eine Verfallszeit der Kacheln festgelegt (in Stunden/Tagen) werden. D.h., wenn die Kachel zu alt ist, wird Sie zum Zeitpunkt der Abfrage der Kachel neu erzeugt. D.h., wenn man an eine Stelle in der Grafik zoomt, werden die Kacheln, wenn nötig, zur Laufzeit neu erzeugt. Dies kann je nach Geschwindigkeit des System jedoch langsamer sein als die Nuztung des TileUpdaters.
Konfiguration
Identifizieren Sie alle Datenbanken, die Sie zum Erzeugen der Kacheln verwendet haben. Diese stehen in Ihrem Darstellungsmodell oder Ihrer MapGuide/MapServer Konfiguration. Diese Datenbankverbindungen müssen im AppBuilder eingerichtet sein (sind sie in der Regel, da man diese Datenbankverbindungen für Suchen oder anderes benötigt).
Legen Sie dann unter "Karten"->"Tile Updater" eine neue Konfiguration an. Drücken Sie im Register "Optionen" links oben bei "Datenbankverbindungen" auf den Knopf "Hinzufügen" und wählen Sie die Datenbank aus.
Wählen Sie bei Oracle und Postgres den Modus
Trigger (ULTRA FAST)aus. Wenn Sie mehrere Datenbanken verwenden, wiederholen Sie diesen Vorgang mit jeder Datenbank.
Wählen Sie im Register "Optionen" links mittig bei "Karten" mittels "Hinzufügen" die passende(n) Tile Server Karte(n) aus. In der Auswahlliste werden die verschiedenen TileServer über @ gekennzeichnet.
Rechts in den Registern Tables und Views können optional weitere Konfigurationen zur Optimierung vorgenommen werden. Beachten Sie, dass die Informationen, die auf der rechten Seite erscheinen, jeweils zur der links in der Liste gerade aktiv gewählten Datenbank gehören.
Es ist ratsam im Register Views alle Views auszuschalten, die nicht in der Karte verwendet werden, wie z.B. Statitic Views etc.. Ansonsten dauert der Tile Updater länger und unnötig Daten. Besonderns bei SQLite Datenbanken ist es ratsam, dies auch beim Register "Tables" zu bearbeiten.
Das Konfigurieren in den Registern Tables und Views ist optional und muss NICHT durchgeführt werden.
Es dient lediglich dazu die Geschwindigkeit des TileUpdaters zu optimieren.
Führen Sie dies bitte nur durch, wenn Sie sich im klaren sind was der Tile Updater macht.
Unbedachte Fehlkonfigurationen führen dazu das ggf, Kacheln nicht erneuert werden.
Bedenken Sie auch, dass, wenn Sie Tabellen oder Views ausschalten, diese wieder einschalten, wenn
Sie diese später doch wieder in der Karte verwenden.
Die Narrensicherste Methode ist KEINE Konfiguration vorzunehmen und dies nur durchzuführen, wenn das Ausführen des TileUpdaters/Kachelns
zu langsam ist oder wenn 100% klar ist, dass Tabellen nicht verwendet werden.
Drücken Sie nun einmalig auf "Hash Initialisieren".
Fügen Sie zum Test einen neuen Geometrie Datensatz in einer Ihrer Tabellen hinzu (zum Beispiel in AutoCAD Map eine Wasserleitung erfassen). Gehen Sie dann auf das Register "Änderungsprotokoll", um zu sehen welche Datensätze geändert wurden.
Drücken Sie dann den "Ausführen" Knopf um den Tile Updater ausführen.
Der Tile Updater erzeugt dann im Verzeichnis
C:\inetpub\wwwroot\MumGeoData\TileUpdater\Invalidate
Ihres Servers XML Dateien, welche die Geometriebereich enthalten, die
neu zu rendern sind.
Am Ende des Vorgangs wird dann der Tile Server gestartet, der mittels den XML Dateien die jeweils von der Änderung betroffenen Kacheln aktualisiert. Dies erfolgt asynchron.
Das Aktualisieren wird vom Tile Server durchgeführt nicht vom Tile Updater! Mit dem "Tile Server Manager" kann beobachtet werden, wann der Tile Server die Kacheln aktualisiert. Das Aktualisieren kann je nach Menge einige Zeit dauern und der Tile Updater weiß nicht, wann der TileServer mit dieser Aktion fertig ist. D.h., nur weil kein Wartebalken nach dem Drücken des "Ausführen" Knopfes mehr angezeigt wird und die UI responsive ist, bedeutet das nicht, dass alle Kacheln neu gerendert wurden. Die Kacheln sind erst fertig gerendert, wenn der Tile Server diese fehlerfrei verarbeitet hat.
Im Register "Änderungsprotokoll" wird in der Spalte "Render Datum" bei den bereits ausgeführten Datensätze
das Datum vermerkt. Sie sehen diese Datensätze, wenn Sie den "nur nicht gerenderte" Knopf deaktivieren.
Mit dem Knopf "Ausführen wiederholen" können Sie ggf. das Render wiederholen, zum Beispiel dann, wenn der TileServer fehlgeschlagen ist.
Bitte beachten: Eine Datenbank darf nicht mehrfach in verschiedenen Konfigurationen verwendet werden, wenn mehrere Konfigurationen unter "Karten"->"Tile Updater" angelegt wurden! D.h., Sie müssen alle Tile Server Karten, die die gleiche Datenbank verwenden in die gleiche Konfiguration aufnehmen.
Hintergrund: Nach dem Ausführen des Tile Updaters auf eine Datenbank werden die Objekte der Datenbank dann als bereits bearbeitet markiert und können daher bei einer anderen Konfiguration nicht nochmal ausgeführt werden!
Kopieren bzw. verdoppeln Sie niemals händisch Tile Updater Konfigurationsdateien!!
Ausführen des Tile Updaters mittel Windows Scheduler (Aufgabenplanung)
Der Tile Updater kann entweder händisch aus dem AppBuilder ausgeführt werden
oder mittels der Datei MapEdit.Executor.exe als Task in den Windows Scheduler
eingebunden werden, um den Tile Updater z.B. jede Nacht ausführen zu lassen.
Um eine optimale Geschwindigkeit zu erreichen sollte der MapEdit.Executor.exe immer auf dem MapEdit Server ausgeführt werden, da dann weniger Daten über das Netzwerk gesendet werden müssen.
Sie können diesen aber auch auf jeder anderem Maschine ausführen, auf der auch der AppBuilder lauffähig ist. Davon ist jedoch abzuraten, wenn Sie sehr sehr große Datenmengen verwalten.
Vorgehen:
- gehen Sie auf den MapEdit Server Rechner,
- starten Sie dort den AppBuilder,
- öffnen Sie die Tile Updater Konfiguration,
- drücken Sie den Knopf "Ausführungstoken erzeugen" und folgenden Sie den dort aufgeführten Anweisungen.
Fügen Sie in der MapEdit.ini Datei die CommandToken Zeile hinzu, die Sie in der Ausgabe sehen.
Dieser Token ist nur für diese aktuelle Konfiguration gültig. Der Token muss erneuert werden, wenn der Name der Konfiguration umbenannt wird oder wenn wenn das Login des angemeldeten Administrator sich ändert.
Wenn Sie mehrere Konfiguration haben, hat jede Konfiguration einen eigenen Token. Nennen Sie diese dann CommandToken1, CommandToken2, CommandToken3 usw.
Starten Sie nach dem Ändern der MapEdit.ini den AppBuilder unbedingt neu!!!
Dies kopiert den Inhalt der Datei MapEdit.ini in die Datei MapEdit.Desktop.ini, die im gleichen Verzeichnis wie die MapEdit.Executor.exe liegt.
Die MapEdit.Executor.exe benötigt diese ini-Datei, um zu wissen mit welchem Server sie sich verbinden muss.
Binden Sie dann den MapEdit.Executor.exe in den Windows Task Scheduler ein. Den vollständigen Pfad zur MapEdit.Executor.exe finden Sie im Ausgabefenster. Als Parameter muss "CommandToken=Token Nummer" angegeben werden:
CommandToken=1
Wenn Sie mehrerer Token haben dann die jeweilige Nummer.
Testen Sie die MapEdit.Executor.exe vor dem Einbinden in den Task Scheduler zuerst in der DOS Box, hier sehen Sie ggf. Fehler. Beachten Sie auch, dass Sie dem Windows Scheduler Task genügend Rechte geben. Der Task benötigt die gleichen Rechte wie der MapEdit AppBuilder. Lassen Sie also den Task unter dem gleichen Windows Benutzeraccount laufen wie den AppBuilder oder verwenden Sie einen Account mit vollen Rechten.
Dos Box Beispiel:
CD C:\Users\Administrator\AppData\Roaming\MapEditDesktop\mkurz\app\
*MapEdit.Executor.exe* CommandToken=1
Die Pfandangabe ist nur beispielhaft und muss angepasst werden.
Wenn Sie in der DOS Box die Meldung "Error: No Token found" bekommen, dann konnte das Programm die Datei
MapEdit.Desktop.ini (oder MapEdit.Executor.ini) nicht im gleichen Verzeichnis wie die MapEdit.Executor.exe
finden oder der Token steht nicht in der ini Datei.
Dies passiert, wenn Sie den AppBuilder nicht neu gestartet haben oder den Token nicht in die ini-Datei des
Rechner eingetragen wurde, sondern auf einem komplett anderen Rechner.
Ab Version 24.1.172 wird eine Datei MapEdit.Executor.log im gleichen Verzeichnis wie die MapEdit.Executor.exe erzeugt.
In dieser finden Sie ggf. Informationen zu Fehlern.
Statt der Nutzung der "MapEdit.Desktop.ini" kann ab Version 24.1.172 alternativ auch eine Datei MapEdit.Executor.ini im gleichen Verzeichnis
wie die MapEdit.Executor.exe angelegt werden. Diese Datei muss mindestens die Parameter MapEditServerUrl, MapEditStorageName und den CommandToken1 enthalten.
Benutzen Sie immer die MapEdit.Executor.exe des im Ausgabefenster angegebenen Pfad, das beim Knopf "Ausführungstoken erzeugen" erscheint.
Die Datei MapEdit.Executor.exe benötigt alle Dateien, die in diesem Pfad vorhanden sind.
Kopieren Sie also nicht die Datei MapEdit.Executor.exe an einen anderen Ort. Das wird nicht funktionieren.
Nach einem MapEdit Software Update muss der AppBuilder auf dem Rechner, auf dem der MapEdit.Executor.exe ausgeführt wird, mindestens einmal gestartet werden, damit die Version der Software auf dem aktuellsten Stand ist.
Es gab einen Fall bei einem Kunden, bei dem die MapEdit.Executor.exe im Windows Scheduler nicht ausgeführt wurde.
Warum das so ist, konnte leider nicht geklärt werden.
Der Kunde konnte sich so behelfen, dass er die MapEdit.Executor.exe aus einer Batch (.bat) Datei
gestartet hat und dann die .bat Datei in den Windows Scheduler eingebunden hat.
Alte XML Dateien vom Server löschen
Mit der Option "Leere XMLs all X Tage" (Im Register Optionen unten bei Einstellungen)
können Sie festlegen nach wieviel Tagen
die XML Dateien im Verzeichnis C:\inetpub\wwwroot\MumGeoData\TileUpdater\Invalidate
gelöscht werden sollen.
Das Löschen findet erst beim nächsten Ausführen des TileUpdaters statt. Der Tile Updater löscht dann alle Dateien, die zu diesem Zeitpunkt älter als X Tage sind. Wenn der Tile Updater nicht ausgeführt wird, werden die Dateien nicht gelöscht!
Alte Log Einträge automatisch leeren
Mit der Option "Leere Änderungsprotokoll alle X Tage" können Sie festlegen, nach wieviel Tagen Log Einträge, die bereits ausgeführt wurden gelöscht werden sollen.
Es kann hilfreich sein, bereits ausgeführte Log Eintrage kurzfristig bei zu behalten, um im Fehlerfall das Rendern der Tiles händisch wiederholen zu können.
Rendern/Ausführen wiederholen
Mit dem "Ausführen wiederholen" Knopf können Render Vorgänge wiederholt werden. Die ist jedoch nur möglich, wenn die Log Einträge noch vorhanden sind.
Erweiterte Konfiguration
Das Programm versucht immer selbst die beste Konfiguration zu setzen.
Eine weitere Konfiguration ist optional und kann von Profis dazu genutzt werden, die Geschwindigkeit des Tile Updaters zu optimieren.
Sie müssen sich dazu aber sehr gut mit Ihrer Datenstruktur auskennen und genau wissen, was sie tun, da bei einer Fehlkonfiguration ansonsten ggf. Kacheln nicht erneuert werden.
Das Register Tables (Tabellen)
Hier erscheinen alle Tabellen die eine FID oder ID Spalte haben.
Sie können zum Optimieren der Geschwindigkeit optional hier die Tabellen, die Sie nicht in ihrer Grafik benutzen ausschalten, indem Sie die "Methode" auf Off (Aus) setzen. (Bei Versionen kleiner 24.2. gibt es die Methode noch nicht, dort verwenden Sie den haken "Aktiv")
Tabellen, die von Views verwenden, die in der Grafik verwendet werden, sollten Sie nicht ausschalten!
Vergessen Sie nicht, ausgeschaltete Tabellen wieder einzuschalten, wenn Sie neue Layer in Karten hinzufügen, die Sie dann doch wieder benötigen!
Tabellen, die keine numerische FID oder ID haben können mit dem Tile Updater nicht genutzt werden.
Für Versionen kleiner 24.2. gilt: Das Ausschalten deaktiviert nicht die Trigger oder das Loggen von Datensatzänderungen der Tabelle, sondern erzwingt nur, dass der Tile Updater diese Änderungen ignoriert. Wenn Sie den Trigger in 24.1. deaktivieren wollen, können Sie den Trigger manuell via SQL deaktivieren. Die Tile Updater Trigger beginnen mit "TRGTU" plus dem Tabellennamen.
Beispiel zum Deaktivieren für Oracle:
ALTER TRIGGER TRG_TU_MEINETABELLE DISABLE;
Achtung: Das Entfernen (droppen) von Tile Updater Triggern hat keine Wirkung, da diese dann beim nächsten Ausführen
des Tile Updater wieder angelegt werden. Deswegen immer via DISABEL arbeiten.
Für Version 24.2. und höher gilt: Methode "off" und "hash" entfernt den Update Trigger und stoppt das Loggen von Datensatzänderungen der Tabelle. Beachten Sie, dass die Definitionen im Register "View" nicht funktionieren, wenn eine dort verwendete Tabelle auf OFF steht. Methode "hash" bei Tabellen erzeugt Hash-Einträge wie bei Views (siehe Views und Hash)
Die Methode "Hash" kann für Tabellen verwendet werden, bei denen ständig alle Datensätze der Tabelle aktualisiert werden. Es werden Trigger für alle Datensätze der Tabelle gefeuert und und dadurch enstehen sehr viele Log-Einträge, obwohl sich ggf. nicht wirklich viel geändert hat. Ein Beispiel sind Materialzed View Tabellen. Die Methode "Hash" ist in diesen Fällen die bessere Wahl.
Für Version 24.2.102 und höher gilt: Tabellen die mit "_CONN" enden (Netzwerktopologie Tabellen) werden zu Beginn automatisch auf "OFF" gesetzt. Die Tabelle "PROTOKOLL" wird zu Beginn automatisch auf "OFF" gesetzt. Diese Tabellen können wenn benötigt eingeschalten werden.
Das Register Views
Bei Tabellen ist es einfach über die Trigger herauszufinden, welche Datensätze sich geändert haben.
Bei Views gibt es leider keine Trigger und hier ist das ganze nicht so einfach.
Das Programm versucht immer automatisch die optimalste Konfiguration selbst zu finden.
Im Register Views erscheinen alle Views, die eine Geometrie Spalte haben. Bei Views, die nicht in der Grafik genutzt werden, sollte in der Spalte "Aktiv" der Haken entfernt werden und bei der Spalte "Methode" sollte "AutoNoAction" stehen.
Diese Option erhöht die Geschwindigkeit besonders bei großen Datenmengen erheblich, sollte aber nur angewendet werden, wenn der View auch wirklich nicht in der Grafik verwendet wird.
Das Verarbeiten der Views mit der Standard Methode "AutoHash" macht das Programm langsam, da bei dieser Option bei jedem Ausführen des Tile Updaters alle Datensätze gelesen, mit dem letzten Zustand verglichen und Informationen zum Zustand gespeichert werden müssen.
Beachten Sie, dass wenn Sie neue Views anlegen, das Programm diese automatisch immer auf "AutoHash" setzt, außer es handelt sich um eindeutige Utility oder Label Views, die nur zwei Tabellen beinhalten und keine weiteren Tabellen.
Bedenken Sie, dass nicht nur Änderungen in der Geometrie den Inhalt einer Kacheln verändern können. Z.B. kann die Farbe einer Linie abhängig von einem Attribut eines Datensatzes dargestellt werden. Oder der Text eines Anschriebs (Labels) hat sich geändert.
Wenn Sie selbst Konfigurationen vornehmen, muss bei "Methode" der Wert "LAUNCH" oder "HASH" stehen und nicht "AUTO xxx" Dieser verhindert, dass Ihre Konfiguration vom Programm überschrieben wird. Achten Sie darauf das "Aktiv" eingeschalten ist.
View Modi
Das Programm bietet für Views drei verschiedene Möglichkeiten an:
Wenn keine Trigger benutzt werden, kann nur die Methode "HASH" benutzt werden. Alle anderen Methoden machen ohne Trigger keinen Sinn.
Methode - Aktiv
Wenn Sie eine View nicht in der Karte verwenden, können Sie diesen hiermit ausschalten. Damit verhindern Sie, dass der Tile Updater unnötig die Änderungen an der Tabelle analysiert und unnötig Kacheln aktualisiert. Es wird außerdem weniger Speicherplatz für diese zusätzlichen Analyse Informationen benötigt.
Methode - Hash
Wird diese Methode verwendet, dann werden in der Tabelle ME_TILEUPDATER_DIFF zu jedem Datensatz des Views
Informationen gespeichert, um festzustellen ob sich etwas an den View Daten geändert hat.
Bei SQLite wird diese Methode auch für Tabellen verwendet.
Beachten Sie, dass dies zusätzlichen Speicherplatz benötigt und dass dieser Vorgang bei großen Datenmengen das Ausführen des Tile Updaters extrem verlangsamen kann.
Verwenden Sie stattdessen wenn möglich immer besser die Methode "Launch". Diese benötigt keinen zusätzlichen Speicherplatz, ist wesentlich schneller, jedoch wird zur Konfiguration Expertenwissen benötigt.
Durch die Option "Use External Hash Database" (auf der rechten Seite) kann die Tabelle ME_TILEUPDATER_DIFF optional
in eine andere Datenbank ausgelagert werden, wenn Sie Ihre Datenbank nicht mit diesen Informationen belasten wollen.
Bei Oracle Datenbanken kann es ggf. auch Geschwindigkeitsgewinne geben, wenn man diese in eine Postgres oder SQLite Datenbank auslagert.
Wenn der Tile Updater Änderungen an einem View Datensatz feststellt, werden diese in der Tabelle ME_TILEUPDATER_LOG geloggt.
Methode - Launch
Hier können Relationen festgelegt, die auslösen (launch), dass ein Datensatz als geändert erkannt wird und der Geometriebereich aktualisiert werden muss.
Die Methode benötigt keinen zusätzlichen Speicherplatz und ist wesentlich schneller als Hash. Verwenden Sie diese Methode nur, wenn Sie wissen, was sie tun.
Das Programm versucht immer selbst bereits die beste Konfiguration zu setzen.
Eine weitere Konfiguration ist nicht notwendig bzw. optional und kann von Profis dazu genutzt werden, die Geschwindigkeit des Tile Updaters zu optimieren, wenn Sie der Meinung sind das der Tile Updater zu langsam läuft.
Sie müssen sich dazu aber sehr gut mit Ihren Datenstruktur auskennen und genau wisse,n was sie tun da bei einer Fehlkonfiguration ansonsten ggf. Kacheln nicht erneuert werden.
Stellen Sie, wenn Sie diese Methode verwenden wollen, die Methode auf "Launch".
Wenn die Methode auf "AutoLaunch" steht werden ihre Einstellungen beim nächsten Starten vom Programm überschrieben!
Launch Table = Tabelle, die die Methode auslöst (im Normalfall eine Attribut Tabelle)
Launch Filter = Filter, der via der Launch Table die Geometry aus der Tabelle Launch Geometry (Table) holt
Launch Geometry (Table) = Tabelle, in der die Geometrie gefunden wird
Der Ablauf:
Das Programm liest die Tabelle ME_TILEUPDATER_LOG. In dieser stehen die geänderten Datensätze.
Wenn das Programm auf eine Tabelle stößt, die auch bei "Launch Table" steht, dann nimmt es den Primarschlüssel der Tabelle (FID/ID)
und ersetzt den Wert {KEY} im Launch Filter mit dieser FID/ID.
Danach wird mit diesem Filter die "Launch Geometry" abgefragt und die Geometrie - und wenn vorhanden die FID - in die Log Tabelle (ME_TILEUPDATER_LOG) eingetragen.
Beispiel:
Ein View enthält die Attributtabelle BAUM und eine Punktgeometrie Tabelle PUNKT mit einem Feld FID_ATTR, in dem ein Verweis auf die BAUM Tabelle steht.
Launch Table = Tabelle BAUM
Launch Geometry (Table) = Tabelle PUNKT
Wird nun ein Datensatz in der Tabelle BAUM geändert, dann wird dieser in die LOG Tabelle geschrieben.
Durch den "Launch" kann nun ausgelöst werden, dass, wenn ein Baum Datensatz verändert wird, dass nun die Geometrie aus PUNKT neu gerendert wird.
Nehmen wir an, die Farbe des Baumes in der Karte ist abhängig von einem Attribut in der Tabelle BAUM.
Dann wird ohne einen Launch (oder Hash) die Kachel nicht neu gezeichnet, da
sich ja die Geometrie in Tabelle PUNKT nicht geändert hat.
Weitere Beispiele ganz unten.
Ab Version 24.2.78 können Sie auch mehrere "Launch" für einen View festlegen.
Markieren Sie dazu den View, der die Methode "Launch" hat und drücken die den Knopf "Launch duplizieren".
Es wird dann ein Eintrag "FixLaunch" erzeugt, den Sie bearbieten können.
Die Methode eines "FixLaunch" Eintrages kann nicht geändert werden!
Um den Eintrag wieder zu entfernen, markieren Sie den erzeugten Eintrag und drücken Sie den Knopf "Fix Launch entfernen".
Wenn Sie mehrere Launch Methoden für einen View verwenden, dann sollten alle Eintrage für diesen View auf "Launch" bzw. "FixLaunch" stehen.
Methode - Auto
Wenn bei Methode eine der Auto-Methoden eingestellt ist (AutoNoAction/AutoLaunch/AutoHash) dann bedeutet das, dass die Methode vom Programm automatisch gewählt wurde. Hier können Sie sehen, welche Methode das Programm benutzt.
Dies wird bei jedem Lauf vom Programm neu gesetzt, da Views sich ändern können oder neue dazu kommen können.
D.h., wenn Sie explizit eine Methode wählen wollen, müssen sie Hash oder Launch wählen und keine der Auto Methoden.
Ohne Trigger arbeiten
Wenn Sie in der Datenbank keine Trigger anlegen wollen, dann wählen Sie beim Hinzufügen der Datenbank die Option "NO TRIGGER".
Beachten Sie, dass dadurch jedoch die Ausführungsgeschwindigkeit
des Tile Updaters erheblich langsamer wird.
Sie sollten diese Option nur dann benutzten, wenn es wirklich notwendig ist.
Weitere Informationen für Insider
Auf Ihrem MapEdit Server werden im Verzeichnis
C:\inetpub\wwwroot\MumGeoData\TileUpdater\Invalidate
XML Dateien abgelegt. Diese Dateien werden an den Tile Server gesendet und enthalten die Geometriebereiche, die sich geändert haben.
Beachten Sie, dass hier keine Tabellennamen oder FIDs stehen, da Geometriebereiche, die sich überlappen vom Programm kombiniert werden,
um die Dateien so klein wie möglich zu halten.
Die Information welche FID und Tabellen sich geändert haben finden Sie in der Tabelle ME_TILEUPDATER_LOG.
Die Dateien sind jeweils maximal 5MB gross, danach wird eine neue Datei erzeugt.
Wenn Sie die Tabellen mit einem SQL Tool direkt anschauen sind alle Datumsangaben immer in UTC Zeit!
Der Tile Updater braucht zu lange, was kann ich tun?
Entfernen Sie bei allen Views und Tabellen, die Sie nicht in der Grafik verwenden den Haken "Aktive".
Verwenden Sie bei Oracle und Postgres immer den Modus "Trigger (UTRA FAST)".
Datenbankverbindung hinzufügen
Wenn Sie hier eine Datenbankverbindung nicht sehen, bedeutet dies, dass diese bereits in einer anderen Tile Server Konfiguration verwendet wird. Eine Datenbankverbindung darf nicht in mehreren Tile Server Konfigurationen verwendet werden, da sich sonst die Daten gegenseitig ueberschrieben.
Beim Hinzufügen einer Datenbank werden die Tabellen ME_TILEUPDATER_LOG und ME_TILEUPDATER_DIFF hinzugefügt
und Trigger für alle Tabellen erzeugt.
Alle Trigger des Tileupdaters sind mit
TRG_TU_*
benannt.
Alle Trigger sind BEFORE INSERT OR DELETE OR UPDATE Row Trigger.
Die Trigger werden immer für ALLE Tabellen angelegt. Der Anwender kann diese nicht einzeln wählen.
Benutze externe Hash Datenbank
Hiermit kann die Tabelle ME_TILEUPDATER_DIFF in eine separate Datenbank ausgelagert werden.
Die Datenbank muss nicht vom gleichen Typ sein. D.h., wenn Ihre Daten in einer Oracle Datenbank sind, kann die "Hash Datenbank" in einer SQLite oder Postgres Datenbank liegen.
Mit diesem Vorgehen können die Daten der Tabelle ME_TILEUPDATER_DIFF ausgelagert werden.
Die Einfügegeschwindigkeit von SQLite und Postgres ist teilweise schneller als die von Oracle.
Legen Sie mit dem AppBuilder eine neue leere Datenbank an. Die Datenbank muss mit dem Namen "_TILEUPDATER" enden!
Wählen Sie diese Datenbank dann bei "Benutze externe Hash Datenbank" aus.
Beim Auswählen wird automatisch die Tabelle ME_TILEUPDATER_DIFF in der Datenbank angelegt.
Achten Sie darauf, diese Datenbank nicht in mehreren Konfigurationen zu verwenden sondern immer nur in einer! Ansonsten werden falsche Ergebnisse erzeugt.
Hash initialisieren
Füllt bzw. aktualisiert die Tabelle ME_TILEUPDATER_DIFF mit Werten ohne das Kacheln neu erzeugt werden.
Mit diesen Werten kann erkannt werden, ob sich Datensätze in Views (oder bei SQLite auch in Tabellen)
verändert haben.
Diese Funktion sollte außer bei initialen Aufsetzen nicht ausgeführt werden. Wird diese doch ausgeführt, dann denkt das Programm, dass keine Änderungen vorhanden waren und führt kein Rendern aus.
Hash leeren
Löscht den Inhalt der Tabelle ME_TILEUPDATER_DIFF
Hash Codes der Views.
Log leeren
Löscht den Inhalt der Tabelle ME_TILEUPDATER_LOG.
Säubern
Löscht aus der Tabelle ME_TILEUPDATER_LOG alle Datensätze die bereits
zum Neuerzeugen von Kacheln verwendet wurden.
Test Ausführen
Führt den Tile Updater aus, fügt aber kein Render Datum ein.
Beim ausführen des TileUpater untersucht das Programm unter anderem ob sich Datensätze von Views (Oder Tabellen mit Methode HASH) verändert haben und schreibt diese Änderungen in das Protokoll (ME_TILEUPDATER_LOG). Desweiteren prüft das Programm ob neue Tabellen oder Views hinzugekommen sind oder entfernt wurden und setzt für diese automatisch Vorgabeeinstellungen.
Test Ausführen (kein Rendern)
Gleich wie "Test Ausführen", führt aber am Ende nicht den Tile Server aus. D.h., es werden keine Kacheln neu gerrendert.
Dieser Knopf kann z.B. auch dazu verwendet werden um alle Änderungen, auch die von Views, LAUNCH und HASH Methoden ins Protokoll (ME_TILEUPDATER_LOG) zu schreiben, da dort ohne ausführen nur die Aenderungen von Triggern zu sehen sind.
Was passiert beim Hinzufügen einer Datenbank zu der Konfiguration?
Beim Hinzufügen werden die Tabellen ME_TILEUPDATER_LOG und ME_TILEUPDATER_DIFF
erzeugt und auf jede Tabelle der Datenbank wird ein Trigger erzeugt. Dieser Trigger schreibt, wenn ein Datensatz erzeugt, geändert oder gelöscht wird, einen
Datensatz in die Tabelle ME_TILEUPDATER_LOG.
Der Datensatz enthält den Tabellen Namen, die FID/ID, das Änderungsdatum und den MBR der Geometry vor und nach der Änderung.
Auf System Tabellen und Tabellen die keine FID/ID haben werden keine Trigger erzeugt.
Bei SQLite werden keine Trigger erzeugt, diese werden intern wie Views behandelt.
Die Tabelle ME_TILEUPDATER_DIFF wird für Views benötigt oder wenn keine Trigger verwendet werden sollen.
Was passiert beim Entfernen einer Datenbank aus der Konfiguration?
Es werden alle Tile Updater Trigger sowie die Tabellen ME_TILEUPDATER_LOG und ME_TILEUPDATER_DIFF entfernt.
Was ist, wenn ich Tabellen/Views hinzufüge oder lösche?
Bei Topobase/AutoCad Map Datenmodellen oder händischem anlegen/löschen oder ändern von Tabellen oder Views via SQL muss immer die Datenbankverbindung im AppBuilder aktualisiert werden. Ansonsten kennt MapEdit dies Tabellen/Views nicht.
Beim Öffnen der Konfiguration oder Ausführen des Tile Updaters werden fehlende Trigger automatisch angelegt und fehlende Konfigurationen automatisch hinzugefügt.
In der Spalte "Definitions Datum" sehen Sie, wann die neue Definition hinzugefügt wurde. Damit erkennen Sie neu hinzugefügte Tabellen und Views.
Direkt nach dem Anlegen neuer Tabellen sollten Sie deshalb die Konfiguration einmalig öffnen, da ansonsten neu eingefügte Datensätze nicht geloggt werden.
Ab Version 24.1.187: Bei MapEdit Datenmodellen werden, wenn neue Tabellen über die Benutzeroberfläche angelegt werden, die Trigger sofort mit angelegt, sofern andere Tabellen Tile Updater Trigger nutzten.
Unterschiede zum "alten" Tile Updater vor Version 24.1.
Der alte Tile Updater funktionierte nur mit Oracle und MapGuide. Der Neue funktioniert auch mit Postgres und SQLite. Er ist unabhängig von MapGuide und kann auch mit MapServer oder anderen Kartenservern genutzt werden.
Bei Änderungen am Datenmodel oder der MapGuide Darstellung musste beim alten Tile Updater jeweils der Tile Updater (deren Dateien) zurück gesetzt und alles neu gerendert werden. Dies ist beim neuen Tile Updater nicht mehr notwendig.
Es gibt beim neuen Tile Updater keine .geom und .hash Dateien mehr.
Für Tabellen werden diese Daten wegen den Triggerm nun nicht mehr benötigt. Damit ist die Ausführungsgeschwindigkeit höher.
Bei Views werden diese Informationen statt in Dateien, in der Tabelle ME_TILEUPDATER_DIFF abgelegt.
Der alte Tile Updater musste zwingend auf dem MapEdit Server ausgeführt werden. Der Neue kann optional auch auf irgendeinem Rechner laufen.
Im neuen TileServer stehen in den XML Dateien nur noch die reinen Geometriebereiche. Hier stehen keine Tabellenamen oder FIDs etc.
Die Informationen, welche Feature sich geändert haben, stehen jeweils in der ME_TILEUPDATER_LOG Tabelle.
Was ist ein HASH?
Um ohne eine Trigger bzw. bei Views zu erkennen, ob sich ein Datensatz verändert hat, werden HASH Werte verwendet.
Ein Hashwert ist eine Zahl, die eindeutig für jede Zeichenkette ist. Das heißt der Text "Hallo" hat fiktiv gesagt den Wert 13 und der Text "Halli" den Wert 29. Dadurch kann man zwei Werte miteinander vergleichen, ohne dass man den eigentlichen Text speichern muss. In unserem Fall wird der alte Zustand eines Datensatzes in Form des Hashwertes gespeichert (der weniger Speicherplatz braucht als die ganzen Daten an Platz brauchen würden).
Wenn nun Daten geändert werden und danach nochmal die Datensätze ausgewertet werden, dann ändert sich bei den geänderten Datensätzen der Hashwert. Die Software erkennt daran, welche Datensätze sich geändert haben. Auch fehlende und neue Datensätze werden erkannt, in dem die Differenz der beiden Zustände ermittelt wird.
Was bedeutet der * in der Spalte "View Tables"
Vor Version 24.1.188 Der * vor einem Tabellennamen bedeutet, dass die Tabelle eine GEOM Spalte hat oder eine Utility Attribut Tabelle ist, die indirekt eine Geometrie hat.
Ab Version 24.1.188 Der * vor einem Tabellennamen bedeutet, dass die Tabelle eine GEOM Spalte hat.
Attribut Tabellen haben doch keine Auswirkung auf die Grafik, wieso werden die geloggt?
Die generelle Annahme, dass reine Attribut Tabellen keine Auswirkung auf die Grafik haben können, ist nicht richtig.
Attribut Tabellen können mit Geometrie Tabellen verknüpft sein und mittels Views (oder ein SQL der beide Tabellen enthält) in der Grafik angezeigt werden.
Beispiel:
Beim Utility Model gibt es eine Tabelle für die Geometrie und eine (oder mehrere) für die Sachdaten.
Zum Beispiel:
Die Attribut Tabelle BAUM, hat keine Geometrie und ein Feld BAUM_TYP.
Die Punkt Tabelle BAUM_PUNKT hat die Geometrie des Baumes und ein Feld FID_ATTR, in der die FID des Baumes in Tabelle BAUM steht.
In der Grafik will man nun alle Bäume je nach BAUM_TYP farblich anders darstellen.
Dazu macht man einen View, in dem BAUM (enthält den BAUM_TYP) und BAUM_PUNKT (enthält die Geometrie) enthalten sind und erzeugt dann Kacheln.
Nun ändert jemand in der Tabelle BAUM den Wert in Feld BAUM_TYP um. Damit muss sich die Farbe des Baumes ändern.
D.h., die betroffene Kachel muss neu gerendert werden, weil in der Attribut Tabelle BAUM eine Änderung passiert ist.
Launch Beispiel an einen Utility View erklärt
Hier ein Beispiel, bei dem das Programm einen Utility View erkannt und automatisch ein Launch Setting erzeugt hat.
Der Utility View EL_V_DSP_BUS_BAR_MS enthält die Tabellen EL_BUS_BAR_MS und EL_POINT.
Aus EL_BUS_BAR_MS kommen die Sachdaten die ggf. in der Grafik angeschrieben werden.
Aus EL_POINT kommt die Geometry des Objektes.
Beachten Sie, dass das Programm nicht weiß, ob und welche Felder des Views der Anwender in der Karte verwendet.
Wenn ein Datensatz in EL_POINT (die Geometrie) und/oder EL_BUS_BAR_MS (Sachdaten) verändert wird, dann wird über den Trigger
jeweils ein Eintrag in der Tabelle ME_TILEUPDATER_LOG erzeugt. Damit weiß der Tile Updater, an welchen Datensätzen geändert wurde.
Nehmen wir an, ein Anwender ändert die Geometrie eines Datensatzes in EL_POINT. Der Trigger erzeugt nun einen Datensatz in ME_TILEUPDATER_LOG mit der FID, dem Tabellennamen EL_POINT und
des neuen und alten Geometriebereiches, wo der Punkt sich befindet.
Wird der Tile Updater ausgeführt, geht dieser alle Datensätze in ME_TILEUPDATER_LOG durch. Es stößt nun auf den Datensatz aus EL_POINT.
Er schaut nun, ob in der Liste der Tabellen (Register Table) die Tabelle EL_POINT aktiv ist.
Wenn ja, dann müssen die Tiles an der Stelle der alten und neuen Geometrie neu gerendert werden.
Diese Information wird in eine XML Datei geschrieben und später zum Tile Server gesendet, der die Kacheln neu erzeugt.
Nun kann es sein das der Anwender nicht die Geometrie EL_POINT geändert hat sondern nur einen Sachdatenwert in Tabelle EL_BUS_BAR_MS. Damit hat sich möglicherweise einen Anschrieb (Label) in der Grafik auf einen anderen Text geändert. Hier kommen nun die Einstellungen des Registers "View" zu greifen.
Der Anwender ändert einen Datensatz in EL_BUS_BAR_MS und über den Trigger wird in ME_TILEUPDATER_LOG
ein Eintrag für EL_BUS_BAR_MS erzeugt, mit der FID die geändert wurde.
Wird der Tile Updater ausgeführt, geht dieser alle Datensätze in ME_TILEUPDATER_LOG durch.
Er findet die Tabelle EL_BUS_BAR_MS nicht im Register "Table", denn hier stehen nur Tabellen die Geometrien haben.
Danach geht er die Liste der View Einstellungen (Register Views) durch.
Hier findet er bei "LAUNCH_TABLE" nun einen Eintrag für die Tabelle EL_BUS_BAR_MS.
Die Einstellung sagt ihm nun, dass die Geometrie zu dieser Tabelle in der LAUNCH_GEOMETRY Tabelle "EL_POINT" steht und über "LAUNCH_FILTER", wie die beiden Tabellen relational verknüpft sind.
Die Verknüpfung ist hier
fid_attr={KEY}
Das Programm fügt nun bei {KEY} die FID von EL_BUS_BAR_MS ein. z.B. 1717 (aus ME_TILEUPDATER_LOG)
und fragt dann die Tabelle EL_POINT ab.
select geom from EL_POINT where fid_attr=1717
Damit findet das Programm die geometrische Stelle, an der die Sachdaten der Tabelle EL_BUS_BAR_MS in der Karte angeschrieben sind und kann nun durch die Geometrie aus EL_POINT die Kachel(n) an dieser Stelle neu generieren.
Step by Step Beispiel
Ausgangslage ist ein Datenmodel mit
- Punkt Tabelle LIBRARY (Büchereien)
- Label Tabelle LIBRARY_LBL (Label Texte der Büchereien)
- Utility Punkt Tabelle BUS_STOP_POINT (Bushaltestellen Geometrie)
- Utility Attribute Tabelle BUS_STOP_ATTR (Sachdaten der Bushaltestellen ohne Geometrie)
- Einen View VU_BUS_STOP_ATTR fuer die Darstellung der Bushaltestellen in der Grafik (BUS_STOP_POINT + BUS_STOP_ATTR)
und anderen Tabellen und Views.
Im Register "Tables" werden alle Geometrie Tabellen mit einem "X" in der Tabelle gekennzeichnet.
Im Register View sehen wir den View "VU_BUS_STOP_ATTR" .
Ausgangszustand: Das Ändergungsprotokoll (Tabelle ME_TILEUPDATER_LOG) ist leer.
Nun ändern wir z.B. mit einem Generic Dialog den Namen einer Bücherei in der Tabelle LIBRARY.
Der Tile Updater Trigger füllt nun die Tabelle ME_TILEUPDATER_LOG mit den geänderten Datensätzen.
Nach drücken von Refresh sehen wir den neuen Inhalt der Tabelle ME_TILEUPDATER_LOG.
Hier steht zu einem der geänderte Datensatz der Tabelle LIBRARY und, weil die Änderung die "Label Feature Rule" ausgelöst hat, eine Änderung im Datensatz LIBRARY_LBL.
Nun ändern wir einen Datensatz in der "Utility Attribute Tabelle" BUS_STOP_ATTR (Sachdaten der Bushaltestellen ohne Geometrie) und drücken "Refresh".
Wir sehen nun im log den geänderten BUS_STOP_ATTR Datensatz.
Nun drücken wir den "Ausführen" Knopf.
Nach drücken von Refresh sehen wir nichts mehr..... da die Datensätze nun verarbeitet wurden.
Entfernen wir die Option "nur nicht gerenderte" dann sehen wir, dass im Log ein Datensatz für "BUS_STOP_POINT"
hinzugefügt wurde. Also die passende Geometrie aus der Änderungen des BUS_STOP_ATTR Datensatzes.
Mit dieser Geometrie weiß man nun, an welcher Stelle in der Grafik Änderungen passiert sind.
Außerdem wurde die Spalte "Render Datum" gefüllt. Damit weiß das Programm, dass und wann das "Kacheln" ausgeführt wurde.
Mit den Geometrien der Log Tabelle weiß nun der Tile Server, welche Kacheln neu gerendert werden müssen.
Hier nochmal die Einstellungen des Views:
Hier die XML Datei, die an den Tile Server geschickt werden. Dieser aktualisiert dann aufgrund der Koordinaten und der angegebenen TileServer Karte die Kacheln der Karte.
Hinweis zu Materialzed Views
Ein Materialized View ist eine physische Tabelle, die das fixe Resultat einer Abfrage enthält. Ein Materialized View ist kein View auch wenn der Name so klingen mag. Ein Materialized View ist eine Tabelle.
Deswegen erscheinen Materialzed Views im Register "Tabellen" und nicht im Register "Views".
Sie können diese selbst testen:
Dieser SQL zeigt in Oracle alle Tabellen
select * from user_tables order by TABLE_NAME
Dieser SQL zeigt in Oracle alle Views
select * from user_views order by VIEW_NAME
Sie werden sehen das Materialzed Views unter "Tabellen erscheinen".
Wenn der Materialized View nicht in der Grafik benötigt wird. sollten Sie bei der Tabelle den Trigger auschalten.
In Version 24.2. und höher
Setzen Sie bei der Tabelle die Methode auf "Off"
In Version 24.1.
Sie müssen den Trigger manuell via SQL deaktivieren.
Die Tile Updater Trigger beginnen mit "TRG_TU_" plus dem Tabellenname.
Beispiel zum Deaktivieren für Oracle:
`ALTER TRIGGER TRG_TU_MEINETABELLE DISABLE;`
Achtung: Das Entfernen (droppen) von Tile Updater Triggern hat keine Wirkung, da diese dann beim nächsten Ausführen
des Tile Updater wieder angelegt werden. Deswegen immer via `DISABEL` arbeiten.
Wenn Sie den Materialized View wirklich in der Grafik benötigen, sollten Sie die Methode auf "Hash" setzen. Sie ist jedoch erst ab Version 24.2 möglich.
Bei Version 24.1. gibt es nur den Umweg einen View auf den Materialized View anzulegen und diesen dann in der Grafik zu benutzten.
Hinweis zu SQLite
Wir raten dazu SQLite Datenbanken nie als Erfassungsdatenbanken zu verwenden. Verwenden Sie dazu das kostenlose Postgres oder Oracle.
SQLite ist nicht für gleichzeitigen schrreibenden Zugriff konzipiert. D.h. Schreibzugriffe können nicht gleichzeitig ausgeführt werden und werden blockiert bzw. nacheinander verarbeitet.
SQLite Datenbanken sollte nur in Ausnahmefällen und dann nur als Auskunftsdatenbank verwendet werden.
Wenn Sie trotzdem SQLite mit dem TileUpdater verwenden wollen, dann geht das nur ohne Trigger. Tabellen werden hier wie Views mit der Methode Hash verarbeitet, also ohne Trigger.
Bekannte Probleme
Kacheln werden nicht neu gerendert
Prüfen Sie das Log des Tile Server, ob darin Fehlermeldungen zu finden sind.
Benutzen Sie den "Ausführen wiederholen" Knopf um den Vorgang nochmals anzustossen.
Auf Ihrem MapEdit Server werden im Verzeichnis
C:\inetpub\wwwroot\MumGeoData\TileUpdater\Invalidate
Wenn es Änderungen gab, muss dort für jede Datenbank-Karten-Kombination mindestens eine XML Dateien stehen. Wenn es keine Änderungen gab wird keine Datei geschrieben. In dieser XML Datei sind die Geometriebereiche zu finden, die geändert wurden. Die Datei kann mit einem Text Editor geöffnet werden.
Mit dem "Tile Server Manager" können Sie beobachten, ob und was der Tile Server gerade ausführt.
Der "Tile Updater" und "Tile Server" sind zwei getrennte Programme. Verwechseln Sie das eine nicht mit dem anderen. Der "Tile Updater" findet heraus, welche Geometriebereiche gekachelt werden müssen. Der "Tile Server" erzeugt (rendert) die Kacheln.
Nur weil der "Ausführen" bzw. "Ausführen wiederholen" Knopf gedrückt wurde und die Benutzeroberfläche keine Aktion anzeigt, bedeutet das nicht das alle Kacheln gerendert wurden.
Das Rendern der Kacheln macht der Tile Updater im Hintergrund. Das kann mit dem "Tile Server Manager" beobachten werden. Schauen Sie auch in das Register "Log" im Tile Server Manager.
Beachten Sie, dass jede Datenbank nur in jeweils einer Tile Updater Konfiguration angegeben werden darf. Es können darin dann aber mehrere Karten angegeben werden.
Kopieren oder verdoppeln Sie nie händisch eine Tile Updater Konfigurationdatei!
Bitte beachten: wenn Sie mehrere Konfigurationen unter "Karten"->"Tile Updater" angelegt haben, das eine Datenbank nicht mehrfach in verschiedenen Konfigurationen verwendet werden darf! D.h. Sie müssen alle Tile Server Karten welche die gleiche Datenbank verwenden in die gleiche Konfiguration aufnehmen.
Hintergrund: Nach dem Ausführen des Tile Updaters auf eine Datenbank werden die Objekte der Datenbank dann als bereits bearbeitet markiert und können daher bei einer anderen Konfiguration nicht nochmal ausgeführt werden!
Informationen zum Tile Server finden Sie auch hier:
https://help.mapedit.de/admin-guide/mapedit-tileserver/
Ich habe einen Datensatz geändert er erscheint aber nicht im Änderungsprotokoll
Im Protokoll sind vor dem Ausführen des TileUpdaters nur Änderungen zu sehen die von Triggern verursacht wurden.
Bei Views und bei Tabellen mit der Methode "HASH" werden Änderungen im Protokoll erst nach dem ausführen des TileUpdaters sichtbar da der TileUpdater diese Änderungen aus den HASH Daten erzeugt.
Bei SQLite werden keine Trigger verwendet, das Protokoll zeigt Änderungen daher erst nach dem Ausführen des Tile Updaters an.
Meine Datenbankverbindung erscheint nicht in der Auswahlliste
Ich drücke den "Hinzufügen" Knopf, um eine Datenbankverbindung hinzuzufügen, aber in der Liste kommt meine Datenbankverbindung nicht.
Dies bedeutet das die Datenbank bereits in einer anderen Konfiguration verwendet wird.
Bitte beachten: wenn Sie mehrere Konfigurationen unter "Karten"->"Tile Updater" angelegt haben, das eine Datenbank nicht mehrfach in verschiedenen Konfigurationen verwendet werden darf! D.h. Sie müssen alle Tile Server Karten welche die gleiche Datenbank verwenden in die gleiche Konfiguration aufnehmen.
Hintergrund: Nach dem Ausführen des Tile Updaters auf eine Datenbank werden die Objekte der Datenbank dann als bereits bearbeitet markiert und können daher bei einer anderen Konfiguration nicht nochmal ausgeführt werden!
Error calling TileServer
Die Meldung:
Error calling TileServer: http://test:8080/TileServer/TileServlet?invalidate&url=http%3a%2f%2fsv000151%2fMumGeoData%2fTileUpdater%2fInvalidate%2fIBA_GA_WP_500.06092022_050018.xml&seq=20220906A050034722
Error Message: The operation has timed out
Bedeutet, dass der TileServer nicht aufgerufen werden konnte.
Der TileServer löscht und erzeugt die Kacheln, nicht der Tile Updater. Der Tile Updater ruft nur den Tile Updater auf und sagt ihm welche Kacheln (via der Koordinaten) neu erzeugt werden müssen.
Wenn der TileServer, warum auch immer, nicht läuft, werden keine Kacheln erzeugt oder ggf. werden nur Kacheln gelöscht und keine neuen erzeugt. Dann den Browser öffnen und die URL, die bei "Error calling TileServer" steht, ausführen.
http://test1:8080/TileServer/TileServlet?invalidate&url=http%3a%2f%2fsv000151%2fMumGeoData%2fTileUpdater%2fInvalidate%2fIBA_GA_WP_500.06092022_050018.xml&seq=20220906A050034722
Wenn diese nicht geht, dann ist da was faul. ggf. kommt dort auch eine Meldung zurück, was nicht stimmt. Z.B., dass die URL falsch ist und es den Server http://test:8080/ nicht gibt (weil vielleicht der TileServer umgezogen wurde oder der Rechner nicht mehr im Netz ist etc) also dieser nicht antwortet.
Wenn die URL läuft aber keine Kacheln erzeugt werden (und wie in dem Fall nur gelöscht werden) dann in das Log vom TileServer schauen, dort wird protokolliert, warum der TileServer nicht geht.
Error Message: The underlying connection was closed: An unexpected error occurred on a receive.
Die Meldung:
Error Message: The underlying connection was closed: An unexpected error occurred on a receive.
Bedeutet, dass es ein Netzwerkproblem gab und der Vorgang mitten drin abgebrochen wurde. z.B. wenn der TileServer Rechner nicht erreichbar ist, weil er mitten drin neu gestartet wurde, oder auch wenn das Netzwerk unzuverlässig ist. Solche Problem muss dann ggf. der Netzwerkfachmann anschauen, warum sein Netzwerk nicht sauber läuft.