Ahnenblattportal

MichaelQ hat geschrieben:
Keine Ahnung ob ich hier richtig bin, einen Hinweis für das Plugin anzubringen (es scheint keine Unterforen für die Plugins zu geben).

Ja, absolut richtig! Aus der Beschreibung des Unterforums:

Erweiterungen zu Ahnenblatt
Plugins, Sprachdateien, Rahmen & Hintergrundgrafiken.

Inhaltlich muss Dir der Autor weiterhelfen.
Marcus

Hallo Michael,

schön, dass Du das Plugin verwendest und danke für die Verbesserungsvorschläge.

Zu a)
Diese Listen sind doch bereits alphabetisch sortiert.
Die Liste der Staaten ist nach den Staatennamen sortiert, nicht nach dem Staatenkürzel.
In der Liste der Territorien sind diese für jedes Land alphabetisch nach dem Namen des Territoriums - nicht nach dem Territoriumkürzel - sortiert.
Zu b)
Das ist ein guter Vorschlag, den werde ich versuchen umzusetzen.
Zu c)
Bei der automatischen Zuordnung der Orte wird der erste Ortseintrag des GOV benutzt, der mit dem zuzuordnenden Ort übereinstimmt. Wenn es mehrere gleichlautende Einträge im GOV gibt, wird oft der falsche Eintrag zugeordnet.
Ist es richtig, dass man für eine Foko-Liste nur Städte oder Orte benötigt?
Was macht man denn, wenn man nur z. B. das Kirchspiel kennt.
Lässt man solche Angaben aus der Foko-Liste draußen?
Wenn dem so ist, dann könnte ich natürlich das GOV entsprechend reduzieren.
Ich dachte bisher, dass man für alle Einträge im GOV auch einen Satz für die Foko-Liste erstellen kann.
Für eine entsprechende Info wäre ich dankbar.

Hallo beinander,
ich wollte mich auch mal wieder zu Wort melden und um entschuldigung bitten ...

ich war monatelang nicht ganz auf dem Damm und habe weder in den Ahnen gegraben noch am PC gesessen. So habe ich mich natürlich auch hier nicht mehr an der Diskussion beteiligen können.

Ich werde Stück für Stück alles nachlesen und ausprobieren ... wird aber noch ein bissl dauern, da auch sehr viele andere Dinge liegen geblieben sind.

Liebe GRüße
Priska

Hallo zusammen,

anbei die neue Version 3.01 des Plugins zum Testen.

Diese läuft ab Ahnenblatt-Version 2.87 und ist somit auf die neue Dateistruktur von Ahnenblatt abgestimmt. Der CSV-Converter wird nicht mehr benötigt.

- Abschied von *.mdb, stattdessen drei Dateien, damit die Mini-GOV leichter (auch von jedem Anwender) aktualisiert werden kann
- Als Name wird der erste Name im SURN-Feld genommen.
- Bei der automatischen Zuordnung wird nur dann automatisch zugeordnet, wenn es den Ortsnamen nur einmal in der Mini-GOV gibt.
- Hilfetext aktualisiert

Dateianhang entfernt wegen neuer Version 3.02

Ohne so recht zu wissen, was ich hier eigentlich mache, kommt beim ersten Klick auf einen Ortsnamen ein Fehler, dass bei mir das "Microsoft.Jet.OLEDB.4.0"-Provider nicht auf dem Computer registriert ist.

Das obere Feld bleibt bei mir z. B. auch komplett leer.

Falls Dir die Meldung spontan nichts sagt, kann ich morgen mal googeln, testen und ggf. installieren (falls hier eine Komponente fehlt, was aber fast nicht sein kann).
Marcus

Hallo Jürgen,

wie auch Marcus eine Fehlermeldung bekommen hatte, habe ich sie auch mehrfach erhalten. Ich habe aber mit dosierten Einsatz der "ESC"-Taste eine Foko-Liste angezeigt bekommen.

Da kommt man aber nun zu den "GOV"-hausgemachten Problemen...
Auch wenn man richtig die Orte geokodiert hat, wie
"Hilversum, Noord-Holland, Niederlande"
dann findet GOV diese nicht, da es die Einzelort-Bezeichnung "Hilversum" erwartet.

Dann kommen die Hürden, wie zwingender Eingabe einer Konfession.
Bei leeren Feldern muss man "Sonstige" (so.) eingeben, obwohl u.U. diese Eingabe nicht richtig ist. Denn man kennt die Glaubensbekennung schlichtweg nicht...

Man sollte GOV beiseite legen und Google (wie bei TNG) die Orte geokodieren lassen. Dann würden die Ortsinformationen zumindest gefunden und man hat dann einen Lati/Long-Datensatz, den man dann in die Foko-DB eintragen kann.

Das bei der Foko-Datenbank man nun seine Eingaben selbst freigeben kann, das sollte man beim AB-Foko-Plugin auch berücksichtigen und die leidigen Pflichtfelder abschaffen.
Wenn etwas nicht weiß, dann bringt es nichts, das man irgendwelche falsche Informationen einfügen muss, nur damit die Foko-Eingabeschnittstelle dies akzeptiert...

Gruß
Olaf

Hallo, vielleicht solltet ihr FOKO mal ein bisserl auf die Seite legen.
Derzeit wird über FOKO diskutiert, ob wiederbelebt, weiterentwickelt, oder sonst was
Arbeitsgruppe ist eingerichtet.

wenn man nicht mehr weiterweiß, bildet man einen Arbeitskreis

FoKo-Suche

Leider sind nicht alle Einträge in der FoKo-Datenbank der eindeutigen GOV-Kennung zugeordnet (Stand 25.05.2010: 86,8 %), so dass nur eine Suche nach dem Ortsnamen alle vorhandenen Einträge zum Ort liefert. Bei Ortsnamen, die mehrfach vorkommen, ist dann darauf zu achten, dass auch Einträge zu gleichnamigen Orten (meist erkennbar an der Postleitzahl) in der Ergebnisliste erscheinen.

Hallo zusammen,

1. Warum bei einigen die Meldung wegen "Microsoft.Jet.OLEDB.4.0"-Provider kommt, weiß ich nicht. Bei mir erschien diese Meldung noch nie.

2. "Hilversum, Noord-Holland, Niederlande" funktioniert! Dieser Ort wird korrekt gefunden und zugeordnet. Er ist auch im GOV enthalten. Olaf bitte nochmals prüfen.

3. Wie ich eben bei einem Test festgestellt habe, sind mittlerweile nur noch die Spalten "Ortsname" und "Name" Pflicht. Ich werde diesen Hinweis in meinen Hilfetext übernehmen und die "*" bei den übrigen Spaltenbezeichnungen entfernen.

4. Zitat:
"Man sollte GOV beiseite legen und Google (wie bei TNG) die Orte geokodieren lassen. Dann würden die Ortsinformationen zumindest gefunden und man hat dann einen Lati/Long-Datensatz, den man dann in die Foko-DB eintragen kann."

Das verstehe ich nicht so ganz. Wenn ich mit FOKO zusammenarbeiten will, muss ich mich an deren Regeln halten. Mein Plugin trennt die Ortsangaben so gut es geht (auch mit Hilfe der Einstellungen im zweiten Karteireiter). Sollte eine automatische Zuordnung dann immer noch nicht funktionieren, bleibt ja noch die manuelle Zuordnung.
Wie kann ich denn einen "Lati/Long-Datensatz in FOKO" eintragen?

5.
Es ist richtig, dass man mittlerweile seine Daten nach dem Upload selbst für die FOKO-Datenbank freigeben kann. Das habe ich eben erst gelesen. Ich werde meinen Hilfetext entsprechend ändern.

6.
Die Diskussion um FOKO ist mir bekannt. Da es derzeit FOKO aber noch gibt werde ich mein Plugin weiterhin updaten, selbst auf die Gefahr hin, dass es kaum jemand verwendet.

Hallo Jürgen,

natürlich ist es natürlich schön, das das Foko-Plugin schon mal in AB v.2.87 läuft. Nun müssen wir unsere lokalen Probleme beheben.

Jürgen T. hat geschrieben:1. Warum bei einigen die Meldung wegen "Microsoft.Jet.OLEDB.4.0"-Provider kommt, weiß ich nicht. Bei mir erschien diese Meldung noch nie.

angehängt findest Du die Fehlermeldung, wenn ich versuche die einzelnen Ort in der GOV-DB zu finden. Nachher kommt immer die Meldung, das die Orte nicht in der GOV-DB (so) enthalten sind.

Jürgen T. hat geschrieben: 2. "Hilversum, Noord-Holland, Niederlande" funktioniert! Dieser Ort wird korrekt gefunden und zugeordnet. Er ist auch im GOV enthalten. Olaf bitte nochmals prüfen.

auch hier kommt die Meldung, das der Ort (so) in der GOV-DB nicht drin ist.
Ich gehe davon aus, das die Zuordnung der Orte mit der "Microsoft.Jet.OLEDB.4.0"-Fehlermeldung zusammen hängt.
Denn nur während allen Aktionen der Orte-Zuordnung kommt dieses "Rufen" nach der Datei...

Ich gehe davon aus, das es etwas mit (meinem) 64bit-Win7 zu tun hat.
Wenn Dein Computer nur mit 32Bit werkelt, dann ist es verständlich, das Du keine Fehlermeldung erhältst.

Jürgen T. hat geschrieben: 4. Zitat:
"Man sollte GOV beiseite legen und Google (wie bei TNG) die Orte geokodieren lassen. Dann würden die Ortsinformationen zumindest gefunden und man hat dann einen Lati/Long-Datensatz, den man dann in die Foko-DB eintragen kann."

Das verstehe ich nicht so ganz. Wenn ich mit FOKO zusammenarbeiten will, muss ich mich an deren Regeln halten. Mein Plugin trennt die Ortsangaben so gut es geht (auch mit Hilfe der Einstellungen im zweiten Karteireiter). Sollte eine automatische Zuordnung dann immer noch nicht funktionieren, bleibt ja noch die manuelle Zuordnung.
Wie kann ich denn einen "Lati/Long-Datensatz in FOKO" eintragen

das wäre in einem Future-Release der Foko-DB sinnvoll. bzw. sollte in der GOV-DB enthalten oder von dieser geliefert/erzeugt werden.

Jürgen T. hat geschrieben: 6.
Die Diskussion um FOKO ist mir bekannt. Da es derzeit FOKO aber noch gibt werde ich mein Plugin weiterhin updaten, selbst auf die Gefahr hin, dass es kaum jemand verwendet.

verwendet schon, denn man kann die Daten nun ja auch mit der aktuellen AB-Version benutzen.
Sofern man keine "Microsoft.Jet.OLEDB.4.0"-Fehlermeldung mehr kommt.

Gruß
Olaf

Hallo Olaf,

ja, ich habe "nur" ein 32 Bit Netbook.
Wäre schade, wenn man das Plugin nicht auf einem 64 Bit Rechner zum Laufen bekäme.

Ja, denke auch dass dies das Problem ist, da es die Treiber wohl nur für 32-bit-Systeme gibt. Ob man die 64bit-Systeme dazu bringen kann die 32bit-Treiber zu nutzen, weiß ich nicht.
Marcus

Einen Ansatz habe ich noch. Falls Du Deine Programme bisher für "Any CPU" kompilierst, hilft es wenn Du in den Eigenschaften des Projekts im Bereich "Erstellen" (bzw. englisch wohl "Build") die Zielplattform ("Target") auf "x86" änderst.
Dein Programm bleibt damit ein 32bit-Programm, es erzwingt aber wohl, dass auch unsere 64bit-Kerne es als ganz gewöhnlichen 32bit-Prozess starten.
Marcus

Gute Idee!
Ich kompiliere tatsächlich für "Any CPU".
Ich werde Deinen Ansatz umsetzen und in der nächsten Pluginversion anbieten.
Danke

hm wenn das klappt könnte man so bestimmt auch das Filter Plugin zum laufen bekommen