Hallo Peter,
eine eindeutige, normierte Pflege der Ortsdaten ist keine Voraussetzung daf�r, dass der richtige Ortsdatensatz in GOV gefunden wird, da die Zuordnung der Ortsdaten zu einer GOV-Kennung ein manueller Akt des Verwalters ist. Das geht �hnlich wie im bisherigen GoogleMaps-Modul (zu jedem Ort wird eine Suche in GOV gestartet und der Admin kann in der Trefferliste die "richtige" GOV-Kennung zuordnen; danach hat man eine Datenbanktabelle mit der Zuordnung der Ortsdaten zu einer GOV-Kennung). Gut gepflegte Ortsdaten machen diesen Schritt einfacher. Ich habe z.B. f�r mich entschieden in den Ortsdaten immer die aktuellen Bezeichnungen der Orte in deren heutiger Landessprache zu verwenden, was die Orte eindeutig macht. Die historischen Ortsnamen kommen ja dann aus GOV.
Ich habe heute die von Dir angeregte M�glichkeit mit den _LOC Datens�tzen implementiert, d.h. man kann diese nun verwenden und die dort eventuell enthaltene GOV-Kennung im _GOV Datensatz wird nun erkannt. Das �ndert aber nichts daran, dass webtrees mit _LOC Datens�tzen nicht wirklich umgehen kann; diese werden zwar eingelesen und abgespeichert, aber ansonsten nicht beachtet und lassen sich nicht bearbeiten. Zum Testen habe ich die Muster-GEDCOM-Datei aus dem GOV-wiki verwendet; klappt gut.
Es gibt nun neben der eigentlich pr�ferierten Verwaltung der GOV-Kennungen in der Datenbanktabelle folgende Alternativen:
1. "_GOV <id>" direkt im PLAC-Record eines Events
2. "NOTE GOV: <id>" zu einem Event
3. "NOTE GOV: GOV :: The Historic Gazetteer; zu einem Event
4. "_LOC @<ref-id>@" Record und dann unter diesem Datensatz ein "_GOV <id>" Datensatz, genau so wie von GEDCOM-L vorgeschlagen
Die Varianten 1 bis 3 sind ung�nstig, weil man die GOV-Kennung bei jedem Mal, wo der Ort auftaucht, wiederholen muss. Die Variante 4 vermeidet das, da es dort die Informationen zu jedem Ort nur einmal gibt und immer darauf verwiesen wird. Das ist der selbe Vorteil wie bei der pr�ferierten Datenbank-L�sung. Der Nachteil der Variante 4 ist, dass webtrees damit (noch) nicht richtig umgehen kann; der Vorteil ist die gute Import/Export-M�glichkeit mit anderen Programmen, die eine solche Ortsdatenverwaltung bereits unterst�tzen (welche sind das?). Der gravierende Nachteil der Datenbank-L�sung ist, dass es keine Export-M�glichkeit gibt; ich �berlege, ob es Sinn machen w�rde, eine Funktion zu realisieren, die die Informationen aus der Datenbank in die GEDCOM-Daten �berf�hrt, also Variante 1 oder 4 erzeugt, wenn man das vor einem Export der GEDCOM-Daten so haben m�chte. Mal sehen. Zumindest der Import von Variante 1 bis 4 geht nun aber.
Viele Gr��e
Hermann