"Wohnort" bearbeiten ...
Beispiel aus der GEDCOM-5.5.1-Spezifikation: (siehe unten!)
Wie Jürgen T. schon gesagt hat, entspricht das dem Standard.
Ahnenblatt 3.0 beta macht das insgesamt so (ein bisschen strukturierter):
Schwarz sehen muss man deswegen nicht. Kann man notfalls auch von Hand korrigieren, indem man eine GEDCOM erzeugt und von Hand die RESI-Einträge mit einem Editor durchschaut. Nur dann bitte die Ziffern alle am Zeilenanfang schreiben, nicht eingerückt, wie im Beispiel oben! Ist doch einen Versuch wert!
Wenn das in der ursprünglichen Datei falsch war, wäre das für Dirk die Möglichkeit, AB für die Zukunft fehlertoleranter zu machen - wäre doch prima!
Mit "Datum" hatte ich übrigens einfach die Einzahl von "Daten" gemeint - keinen Termin. Aber ich gebe zu, dass das missverständlich war, weil der Begriff selten so benutzt wird. (https://de.wikipedia.org/wiki/Daten)
Aber auch wenn wir jetzt dem Problem auf der Spur sind: In AB 2.99 wirst du das auch korrigiert nicht bearbeiten können - nur in AB 3.0 (beta).
Frido
Code: Alles auswählen
1 RESI
2 ADDR 73 North Ashley
3 CONT Spencer, Utah UT84991
2 DATE from 1900 to 1905
Ahnenblatt 3.0 beta macht das insgesamt so (ein bisschen strukturierter):
Code: Alles auswählen
1 RESI
2 PLAC München (Ort als Teil des Fakts)
2 DATE 20 OCT 2008
2 ADDR Hirschgasse
3 CITY München (Ort als Teil der Adresse)
3 POST 8000
Wenn das in der ursprünglichen Datei falsch war, wäre das für Dirk die Möglichkeit, AB für die Zukunft fehlertoleranter zu machen - wäre doch prima!
Mit "Datum" hatte ich übrigens einfach die Einzahl von "Daten" gemeint - keinen Termin. Aber ich gebe zu, dass das missverständlich war, weil der Begriff selten so benutzt wird. (https://de.wikipedia.org/wiki/Daten)
Aber auch wenn wir jetzt dem Problem auf der Spur sind: In AB 2.99 wirst du das auch korrigiert nicht bearbeiten können - nur in AB 3.0 (beta).
Frido
Zuletzt geändert von Fridolin am 08.05.2019, 21:19, insgesamt 1-mal geändert.
Aktuell Win10-64 pro 2004, Ahnenblatt 3.46 - Daten via NAS, Programm lokal
Empfehlung: Für die neue Version 3.x alle relevanten Handbücher lesen!
(es gibt das Benutzerhandbuch und mehrere Themen-Specials!)
Empfehlung: Für die neue Version 3.x alle relevanten Handbücher lesen!
(es gibt das Benutzerhandbuch und mehrere Themen-Specials!)
Entschuldigung, ein Fehler von mir:
Das erste Beispiel oben mit der persönlichen Wohnanschrift aus Utah ist _nicht_ Teil der Spezifikation! Jörb Daub hat es in seine Übersetzung des Standards zusätzlich mit aufgenommen - aber ohne Quellenangabe. Es erhebt also keinen Anspruch auf irgend eine Autorität!
Frido
Das erste Beispiel oben mit der persönlichen Wohnanschrift aus Utah ist _nicht_ Teil der Spezifikation! Jörb Daub hat es in seine Übersetzung des Standards zusätzlich mit aufgenommen - aber ohne Quellenangabe. Es erhebt also keinen Anspruch auf irgend eine Autorität!
Frido
Aktuell Win10-64 pro 2004, Ahnenblatt 3.46 - Daten via NAS, Programm lokal
Empfehlung: Für die neue Version 3.x alle relevanten Handbücher lesen!
(es gibt das Benutzerhandbuch und mehrere Themen-Specials!)
Empfehlung: Für die neue Version 3.x alle relevanten Handbücher lesen!
(es gibt das Benutzerhandbuch und mehrere Themen-Specials!)
Hallo Jürgen,Jürgen T. hat geschrieben:Es könnte daran liegen, dass der Ort "Wuppertal ???" bei Dir in der Zeile "Resi" gespeichert wird/ist, er aber in einer zusätzlichen Zeile "PLAC" stehen müsste.
ich habe die Original AHN DATA Gedcom Datei mal in AB eingelesen und wieder ein Personenblatt erstellt (es wurde hierbei noch nichts mit AB verändert!)
Diese Original Datei habe ich auch wieder mit dem Editor geöffnet und den Kopf der Gedcom Datei und den betreffenden Ausschnitt zum Vergleich abgebildet.
Im schon vorher, in diesem Post abgebildeten Ausschnitt, wurden in AB schon Korrekturen/Änderungen vorgenommen.
Nochmal:
Das stellt sich für mich so dar, daß in der Original AHN DATA Gedcom Datei bei PLAC jeweils der Geburts- und dann Taufort eingefügt ist. Und in RESI eben der Wohnort.Jürgen T. hat geschrieben:Es könnte daran liegen, dass der Ort "Wuppertal ???" bei Dir in der Zeile "Resi" gespeichert wird/ist, er aber in einer zusätzlichen Zeile "PLAC" stehen müsste.
Gruß,
Horst
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Hallo Frido,Fridolin hat geschrieben:Beispielaus der GEDCOM-5.5.1-Spezifikation: (siehe unten!)Wie Jürgen T. schon gesagt hat, entspricht das dem Standard.Code: Alles auswählen
1 RESI 2 ADDR 73 North Ashley 3 CONT Spencer, Utah UT84991 2 DATE from 1900 to 1905
Ahnenblatt 3.0 beta macht das insgesamt so (ein bisschen strukturierter):Schwarz sehen muss man deswegen nicht. Kann man notfalls auch von Hand korrigieren, indem man eine GEDCOM erzeugt und von Hand die RESI-Einträge mit einem Editor durchschaut. Nur dann bitte die Ziffern alle am Zeilenanfang schreiben, nicht eingerückt, wie im Beispiel oben! Ist doch einen Versuch wert!Code: Alles auswählen
1 RESI 2 PLAC München (Ort als Teil des Fakts) 2 DATE 20 OCT 2008 2 ADDR Hirschgasse 3 CITY München (Ort als Teil der Adresse) 3 POST 8000
Wenn das in der ursprünglichen Datei falsch war, wäre das für Dirk die Möglichkeit, AB für die Zukunft fehlertoleranter zu machen - wäre doch prima!
Mit "Datum" hatte ich übrigens einfach die Einzahl von "Daten" gemeint - keinen Termin. Aber ich gebe zu, dass das missverständlich war, weil der Begriff selten so benutzt wird. (https://de.wikipedia.org/wiki/Daten)
Aber auch wenn wir jetzt dem Problem auf der Spur sind: In AB 2.99 wirst du das auch korrigiert nicht bearbeiten können - nur in AB 3.0 (beta).
Frido
danke für Deine Ausführungen.
Ich befürchte halt, daß, wenn ich das alles händisch korrigiere, sich womöglich irgendwo dabei ein Fehler einschleicht der evtl. übersehen wird und mir meine lange Arbeit verfälscht. Mit einer Kopie würde ich allerdings sowieso arbeiten.
Meinst Du, Dirk schaut sich diesen Post an, oder wie meinst Du das?
Gruß,
Horst
Dirk schaut immer mal wieder in unser Forum. Was er aber alles mitbekommt und ob er in jeden Gesprächsteil schaut, weiß ich nicht. Es mag nicht schaden, ihm eine kurze eMail zu schreiben mit dem Verweis auf dieses Gespräch.
Die Adresse deines Startbeitrags: http://www.ahnenblattportal.de/viewtopi ... 7314#57314. Findet man immer mit einem Rechtsklick auf das kleine Dokumentensymbol vor dem "Verfasst am:"-Text. Die eMail-Adresse von Dirk ist in der Info des Programms versteckt: ? > Info.
Dass dir das händische Reparieren heikel vorkommt, kann ich nachvollziehen. Ich hätte keine Sorgen mit einem gescheiten Editor wie notepad++, mit dem man auch Kontrolle über den Zeichensatz und den Zeilenumbruch hat.
Frido
Die Adresse deines Startbeitrags: http://www.ahnenblattportal.de/viewtopi ... 7314#57314. Findet man immer mit einem Rechtsklick auf das kleine Dokumentensymbol vor dem "Verfasst am:"-Text. Die eMail-Adresse von Dirk ist in der Info des Programms versteckt: ? > Info.
Dass dir das händische Reparieren heikel vorkommt, kann ich nachvollziehen. Ich hätte keine Sorgen mit einem gescheiten Editor wie notepad++, mit dem man auch Kontrolle über den Zeichensatz und den Zeilenumbruch hat.
Frido
Aktuell Win10-64 pro 2004, Ahnenblatt 3.46 - Daten via NAS, Programm lokal
Empfehlung: Für die neue Version 3.x alle relevanten Handbücher lesen!
(es gibt das Benutzerhandbuch und mehrere Themen-Specials!)
Empfehlung: Für die neue Version 3.x alle relevanten Handbücher lesen!
(es gibt das Benutzerhandbuch und mehrere Themen-Specials!)
Ich "spiele" gerade etwas mit AB 3.0 Beta herum - ist schon toll, was da alles möglich ist
Dabei ein mir (noch?) unerklärlicher Effekt:
Wenn ich z.B. die von mir bisher als Beispiel für mein "Wohnort Problem" genutze Person aufrufe, dann steht unter DATEN bei WOHNORT nichts im Eingabefeld hierfür. Aber wenn ich von dieser Person ein PERSONENBLATT erstelle, ist der WOHNORT mit den störenden, so nicht gewünschten Einträgen, gefüllt.
Gebe ich aber jetzt bei dieser Person den von mir gewünschten Wohnort-Eintrag ein, so taucht beim neuen Personenblatt-Ausdruck ab sofort der geänderte, richtige Eintrag auf. Hat jemand eine Erklärung für dieses Verhalten ??
@ Frido und Alle
Findet Ihr, daß man AB 3.0 Beta inzwischen als vollwertig und stabil nutzen könnte?
Die Familiendatei *.ahn bleibt ja auch bei der zukünftigen, fertigen Version uneingeschränkt nutzbar.
Dabei ein mir (noch?) unerklärlicher Effekt:
Wenn ich z.B. die von mir bisher als Beispiel für mein "Wohnort Problem" genutze Person aufrufe, dann steht unter DATEN bei WOHNORT nichts im Eingabefeld hierfür. Aber wenn ich von dieser Person ein PERSONENBLATT erstelle, ist der WOHNORT mit den störenden, so nicht gewünschten Einträgen, gefüllt.
Gebe ich aber jetzt bei dieser Person den von mir gewünschten Wohnort-Eintrag ein, so taucht beim neuen Personenblatt-Ausdruck ab sofort der geänderte, richtige Eintrag auf. Hat jemand eine Erklärung für dieses Verhalten ??
@ Frido und Alle
Findet Ihr, daß man AB 3.0 Beta inzwischen als vollwertig und stabil nutzen könnte?
Die Familiendatei *.ahn bleibt ja auch bei der zukünftigen, fertigen Version uneingeschränkt nutzbar.
'
Gruß und BLEIBT GESUND,
Horst
Ich arbeite mit
Windows 11 - Professional - (Vers. 22H2-22623.1325) - 32 GB RAM
AB 3.53
Gruß und BLEIBT GESUND,
Horst
Ich arbeite mit
Windows 11 - Professional - (Vers. 22H2-22623.1325) - 32 GB RAM
AB 3.53
Ja, das Format der *.ahn-Datei ist bei der 2.99 und der 3.0-beta gleich. Man kann mit den Daten wechseln zwischen beiden Versionen.HoWo hat geschrieben:@ Frido und Alle
Findet Ihr, daß man AB 3.0 Beta inzwischen als vollwertig und stabil nutzen könnte?
Aber die obige Frage stellst du am falschen Tag! Bis gestern hätte ich sie uneingeschränkt bejaht: Seit über einem Jahr im Praxistest, ständig nachgebessert und korrigiert, sicherlich tauglich für die praktische Arbeit, solange man sich daran hält, regelmäßige Backups aufzubewahren (meiner Meinung nach mindestens 1 Backup pro Update-Version - und zwar alle dauerhaft aufbewahren, nicht nur die letzte!).
Aber ein Bericht von gestern macht mich vorsichtiger: Da werden gerade Vornamen vertauscht beim Editieren. Wohl dem, der das sofort merkt! Holzauge, sei wachsam!
Ich bleibe trotzdem dabei - aber die 3.0-beta21 werde ich vermutlich überspringen. Ich war noch nicht dazu gekommen, sie zu installieren.
Frido
Aktuell Win10-64 pro 2004, Ahnenblatt 3.46 - Daten via NAS, Programm lokal
Empfehlung: Für die neue Version 3.x alle relevanten Handbücher lesen!
(es gibt das Benutzerhandbuch und mehrere Themen-Specials!)
Empfehlung: Für die neue Version 3.x alle relevanten Handbücher lesen!
(es gibt das Benutzerhandbuch und mehrere Themen-Specials!)
- DirkB
- Administrator
- Beiträge: 1065
- Registriert: 20.01.2006, 20:25
- Wohnort: Hamburg
- Danksagung erhalten: 1 Mal
- Kontaktdaten:
Hallo Horst,
Hier im Forum steht schon viel Richtiges.
Das GEDCOM-Konstrukt ...
1 RESI Wohnort
... ist so (laut GEDCOM-Standard) nicht zulässig und müsste ...
1 RESI
2 PLAC Wohnort
... heißen.
Nun ist aber Ahnenblatt ziemlich tolerant und verwirft kein "falsches" GEDCOM (könnte ja sein, dass das wieder in AhnData eingelesen werden soll). Wie Ahnenblatt dann programmintern mit solchen falschen Konstrukten umgeht, kann man natürlich nicht vorhersehen (auch ich nicht). Es ist auch müßig für alle denkbar falschen GEDCOM-Konstrukte programmtechnisch ein in allen Belangen korrektes Verhalten reinzuprogrammieren.
Hier also der Fall, dass der Wohnort im Personenblatt erscheint, sich aber nicht editieren lässt. Es kommt auch noch hinzu, dass beim Versuch den Wohnort zu editieren, dieser dann komplett verschwindet, danach also auch nicht mehr im Personenblatt erscheint.
Ich werde daher mal eine Logik ranprogrammieren, die den Wohnort korrigiert. Bei allen (anderen) Ereignissen werde ich das aber nicht vorsehen.
Für alle Mitleser:
Die Daten stammen aus diesem alten "Schätzchen" der Programmierkunst:
http://genwiki.genealogy.net/AHN-DATA
Gruß, Dirk
Hier im Forum steht schon viel Richtiges.
Das GEDCOM-Konstrukt ...
1 RESI Wohnort
... ist so (laut GEDCOM-Standard) nicht zulässig und müsste ...
1 RESI
2 PLAC Wohnort
... heißen.
Nun ist aber Ahnenblatt ziemlich tolerant und verwirft kein "falsches" GEDCOM (könnte ja sein, dass das wieder in AhnData eingelesen werden soll). Wie Ahnenblatt dann programmintern mit solchen falschen Konstrukten umgeht, kann man natürlich nicht vorhersehen (auch ich nicht). Es ist auch müßig für alle denkbar falschen GEDCOM-Konstrukte programmtechnisch ein in allen Belangen korrektes Verhalten reinzuprogrammieren.
Hier also der Fall, dass der Wohnort im Personenblatt erscheint, sich aber nicht editieren lässt. Es kommt auch noch hinzu, dass beim Versuch den Wohnort zu editieren, dieser dann komplett verschwindet, danach also auch nicht mehr im Personenblatt erscheint.
Ich werde daher mal eine Logik ranprogrammieren, die den Wohnort korrigiert. Bei allen (anderen) Ereignissen werde ich das aber nicht vorsehen.
Für alle Mitleser:
Die Daten stammen aus diesem alten "Schätzchen" der Programmierkunst:
http://genwiki.genealogy.net/AHN-DATA
Gruß, Dirk
Hallo Dirk,
erst mal herzlichen Dank für Deine Hilfsbereitschaft !
Mal abgesehen von Deiner vorgesehenen Änderung in AB, meine oben
geschilderte Beschreibung, kann doch das Problem, zumindest vorerst, überbrücken, oder ?
erst mal herzlichen Dank für Deine Hilfsbereitschaft !
Mal abgesehen von Deiner vorgesehenen Änderung in AB, meine oben
HoWo hat geschrieben:... ein mir (noch?) unerklärlicher Effekt:
Wenn ich z.B. die von mir bisher als Beispiel für mein "Wohnort Problem" genutze Person aufrufe, dann steht unter DATEN bei WOHNORT nichts im Eingabefeld hierfür. Aber wenn ich von dieser Person ein PERSONENBLATT erstelle, ist der WOHNORT mit den störenden, so nicht gewünschten Einträgen, gefüllt.
Gebe ich aber jetzt bei dieser Person den von mir gewünschten Wohnort-Eintrag ein, so taucht beim neuen Personenblatt-Ausdruck ab sofort der geänderte, richtige Eintrag auf. Hat jemand eine Erklärung für dieses Verhalten ?? ...
geschilderte Beschreibung, kann doch das Problem, zumindest vorerst, überbrücken, oder ?
'
Gruß und BLEIBT GESUND,
Horst
Ich arbeite mit
Windows 11 - Professional - (Vers. 22H2-22623.1325) - 32 GB RAM
AB 3.53
Gruß und BLEIBT GESUND,
Horst
Ich arbeite mit
Windows 11 - Professional - (Vers. 22H2-22623.1325) - 32 GB RAM
AB 3.53