Gedcom: unbekannte Tags nicht in "NOTE" schreiben

[ojay]

Moin,

bei verwandt.de gibt es mehrere erzeugte "spezifische" Gedcom-Tags.
Ahnenblatt aber schreibt (für AB) unbekannte Tags aber in "Anmerkungen" (NOTE)
Ich möchte aber das Ahnenblatt diese unverändert lässt.
Mit AB möchte ich (erstmal) nur 300-400 Personen mit "Gruppe löschen" aus dem Stammbaum entfernen. (denn das bietet verwandt.de nicht an...)
Es muss doch einfach möglich sein, das die Tags unverändert bleiben.

Ich habe bisher nur die Auswahl gefunden, das entweder unbekannte Tags unter "Anmerkungen" geschrieben oder gelöscht werden.

Ergänzung: Hat sich für verwandt.de-Benutzer erstmal erledigt. Denn die (auch von Dirk abgewandelte AB-Version) Home-Edition kann das. Da ist das Programm doch mal brauchbar und es kann vielleicht gar etwas, was AB nicht kann...

Gruss
Olaf

[Hugo]

Guten Tag Olaf
Dein Beitrag brachte mich ins grübeln und in Verwirrung zugleich
Kannst Du mir bitte helfen, diesen Verwirrungsknoten zwischen meinen Ohren zu lösen
Zumal mir keine Gedcom-Datei aus verwandt de bekannt ist (somit auch nicht ihre TAGs)

bei verwandt de gibt es mehrere erzeugte "spezifische" Gedcom-Tags.

Persönlich mag ich keine Programme, egal ob Online oder Offline, die ihren eigenen Standart erstellen

Ahnenblatt aber schreibt (für AB) unbekannte Tags aber in "Anmerkungen" (NOTE)

So ist es eigentlich der internationale Standart quer durch die Programme

Ich möchte aber das Ahnenblatt diese unverändert lässt.

Genau hier beginnt die Verwirrung
Wie stellst Du Dir das vor
Wo sollen diese für Ahnenblatt unbekannten TAGs beim Import landen

In Deiner Ergänzung hast Du geschrieben, das es die Home-Edition kann
Wie ist es dort gelöst

Gruß Hugo

[Torquatus]

Hallo Hugo,

Wie ist es dort gelöst

hm, wohl auch nicht. Siehe unten (aus verwandt.de HomeEdition Vers. 1.2)

Das dortige Menü ist total verbogen und der Gedcom-Import total schlicht. Aber wenn der Import alles macht, was er will, dann hat er ja was er sucht

[Wolf]

Also eine Lösung wäre die Daten aus unbekannten Tags in einen Zwischenspeicher zu schieben um sie später wieder unverändert an die betreffenden Personen zu hängen. Wenn dies nicht mehr bei den anderen Notizen erfolgt ist das Problem eigentlich gelöst.
Und wieder ein Vorteil gegenüber anderen Programmen wäre errungen.. auch wenn ich grundsätzlich auch der Meinung bin, dass Eigenarten nicht schön sind.

[Hugo]

Guten Tag

Also eine Lösung wäre die Daten aus unbekannten Tags in einen Zwischenspeicher zu schieben um sie später wieder unverändert an die betreffenden Personen zu hängen.

Was für einen "Zwischenspeicher"
Wie bekomm ich die zB in fest in eine Offline-Datenbank gespeichert und wo
Vor allen, wo wären sie dann sichtbar

Merk schon, Fragen über Fragen
Gibt es bei verwandt de eventuell eine Beispiel-Gedcom, um damit quertesten zu können

Oder könnte uns jemand einen kompletten INDI Block (anonymisiert) zur Verfügung stellen
Interessant wäre natürlich auch eine Doku, was die "spezifischen" Gedcom-TAGs bedeuten sollen

Gruß Hugo

[Wolf]

Was für einen "Zwischenspeicher"

Den gibt es eben (meines Wissens) noch nicht, es könnte aber ein Bereich sein, der Aussagt: Diese Daten wurden folgendermaßen aus GEDCOM importiert und sind für ein erneutes Speichern als GEDCOM vorgesehen.
Also letztlich nichts anderes als ein weiteres "Notizfeld".

Vor allen, wo wären sie dann sichtbar

Eventuell garnicht. Zumindest ist das nicht erforderlich wenn die Daten beim Speichern wieder da sind. Bei einem Re-Import in Verwandt.de (oder einem anderen Programm mit proprietären Tags) wäre sie wieder da..

Merk schon, Fragen über Fragen
Gibt es bei verwandt de eventuell eine Beispiel-Gedcom, um damit quertesten zu können

Da hast du recht. Nein gibt es nicht soweit ich sehen kann.

Oder könnte uns jemand einen kompletten INDI Block (anonymisiert) zur Verfügung stellen

Natürlich..

Interessant wäre natürlich auch eine Doku, was die "spezifischen" Gedcom-TAGs bedeuten sollen

Ich denke das dürfte dann verständlich werden.

Ansonst haben sich schon Nutzer bei verwandt.de "beschwert" was diese Murkserei soll - aber Erfolg sieht anders aus. Es fehlen auch einige Angaben im Export und andere dafür die man in einer Datei über Ahnen nicht erwarten würde hingegen schon.. naja, eventuell wird das irgendwann mal besser -.-

Letztlich ist es natürlich kein Fehler bei AB, aber zur verbesserung der Konsitenz wäre ein beibehalten der Daten "schöner" als das Löschen und neu erfassen.

Hier der Dateianfang bis zum Ende des ersten Individuums:

Code: Alles auswählen

0 HEAD
1 FILE familytree-Name.ged
1 SOUR VERWANDT
2 VERS 1.0
2 NAME verwandt.de - Home Edition
2 CORP OSN Online Social Networking GmbH
3 ADDR Heimhuder Str. 72
4 CITY Hamburg
4 STAE Hamburg
4 POST 20148
4 CTRY Germany
3 PHON +49 (0)40 238 49 140
3 PHON +49 (0)40 415 457 14
3 EMAIL info@verwandt.de
3 WWW www.verwandt.de
1 GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 DATE 10 MRZ 2009
2 TIME 20:54:27
1 CHAR UTF-8
1 SUBM @S5839661@
1 _NAVM 2
2 _NAVI @5839661@
1 PLAC
2 FORM street, postal_code, city, region, country 
0 @S5839661@ SUBM
1 NAME Vorname Nachname
0 @5889221@ INDI
1 SEX M
1 NAME Vorname2 /Nachname2/
2 GIVN Vorname2
2 SURN Nachname2
1 RESI
2 PLAC Straße2,PLZ2,Ort2,,Schweiz
1 _VWRESI
2 DATE FROM 1 FEB 2002
2 PLAC ,,Ort3,,Deutschland
1 _VWRESI
2 DATE FROM 1 FEB 2004
2 PLAC ,,Ort4,,Deutschland
1 BIRT
2 DATE ABT 4 FEB 1959
2 PLAC ,,,,Deutschland
1 OCCU Filialleiter
2 PLAC ,,,,
1 _VWOCCU Kaufmann
2 PLAC ,,,,
1 RELI -
1 _VWFLD
2 _SLAN Deutsch
2 _SLAN Englisch
1 _VWCNT
2 _SVADR +41433221091
2 _TYPE PHONE
1 _VWCNT
2 _SVADR +4197764559
2 _TYPE CELLPHONE
1 _VWCNT
2 _SVADR az@email.de
2 _TYPE EMAIL
1 RIN 5889221_25
1 CHAN
2 DATE 10 MRZ 2008
3 TIME 21:07:49
1 FAMC @125@
1 FAMS @149@

[ojay]

Moin,

ich habe heute lange mit AB versucht das zu lösen, aber ich habe keine Einstellung gefunden, die der Lösung mit der Home-Edition entsprach.

Ich hätte nicht gedacht, das das Clone von Ahnenblatt diese Tags unangetastet läßt.

Ich brauche das nämlich für TNG. Da verwandt.de massenhaft Daten aufnimmt, so kann man sie relativ einfach auch in TNG importieren.
Wenn man jeweils den Datenschutz (//) und dann das spezifische verwandt.de-Kürzel (_VW) vom Tag jeweils abschneidet, dann sind die Daten schon fertig für den Import.

Das kann nur die Home-Edition. Und da hat Dirk für verwandt.de etwas Gutes entwickelt (und deren Gedcom-Datei gerettet)

Gruß

Olaf

[Torquatus]

Klar, alles was man sich zu Daten ausdenken kann, ist auch machbar. Wenn Dirk beim Import von Gedcom-Daten alle unbekannten Gedcom-Tags je Person in eine Textdatei mit speziellem Namen+Lfd-Nummer stellt und die im Bilddateien-Verzeichnis (oder einem speziellen) abspeichert, dann könnte er diese Gedcom-Tags beim Exportieren dort wieder herausholen und den Gedcom-Daten der jeweiligen Person hinzufügen.

Dabei stelle ich mir aber die Frage: Wofür das Ganze?

Ich diskutiere gerne über die Möglichkeiten anderer Genealogie-Programme (auch der Home-Edition von verwandt.de) und Vergleiche zu Ahnenblatt. Aber ich habe keinen Bock, mir darüber Gedanken zu machen, was in den Gedcom-Datensätzen von verwandt.de enthalten ist und wie man diverse Besonderheiten evtl. nach Ahnenblatt importieren könnte (auch wenn die "verwandt.de-Home Edition" das offenbar kann).

[Marcus]

Diese Option macht für Ahnenblatt auch schlicht keinen Sinn Insofern Hugo, hast Du kein Problem und Deine Fragen führen zum Punkt: Dass dies in Ahnenblatt (streng genommen in keinem (Ahnen-)Programm) nicht sinnvoll ist.

Wenn ich Daten importiere, dann muss ich sie
a) entweder irgendwo in meinem Programm ablegen, damit ich sie nutzen kann
b) löschen, da ich sie nicht mehr benötige

Der Punkt:
c) aufheben um sie beim speichern wieder unangetastet rückzuschreiben

mag für manchen Nutzer (anderer Programme) ganz interessant sein, aber dafür benötigt man dann eine unabhängige Software zum bearbeiten von Gedcom-Dateien! Wer z.B. oben skizziertes Beispiel umsetzen möchte (Daten importieren, Teil löschen und in der alten Struktur (!) wieder exportieren), braucht eine eigene Software. Dies macht für Ahnenblatt (und auch anderen Programme wie PAF, Ahnen-Chronik etc.) und seine Nutzer keinen Sinn! Das muss (in diesem Fall) die Home-Edition oder ein eigenes Tool können. Alles andere würde beim Import zu einer versteckten Informationsvernichtung führen (wenn man die Funktion nicht genau für diesen Zweck nutzt). Die Funktion hätte für Ahnenblatt und seine Nutzer schlicht keinen Nutzen.
Marcus

[Hugo]

Guten Tag Wolf
Herzlichen Dank für Deine Erklärung und vor allem dem INDI-Block
Dadurch haben sich all meine Fragen in Luft aufgelöst

Gruß Hugo

[bjew]

@ojay:

Die HOME EDITION für verwandt.de kennt die Datenbasis *.ahn nicht, sondern lediglich *.ged *.xml und *.csv

Dadurch wird es erheblich leichter , beliebige TAGs zu speichern und zu verarbeiten - wobei nach wie vor offen ist, um welche TAGs es sich handelt, ob es lediglich die verwandt.de-spezifischen sind - und dann auch noch alle möglichen Ausprägungen.
Auch PAF kann das nicht.

Für Dirk ist der Knackpunkt sicher nicht die Erkennung und die Verarbeitung der TAGs, sondern eher die korrekte Ablage in der Datenbasis *.ahn.

Ansonsten, ich habe in der Home Edition bisher nichts entdeckt, was mich bewegen könnte, dorthin umzusteigen. Auch nicht nach verwandt.de.

[ojay]

Moin,

als ich das Thema gestartet habe, da hatte ich noch nicht die Home-Edition getestet. Ich habe sie immer nur mal gespeichert, um sie mal zu haben...

Ich schwöre natürlich auch nicht auf verwandt.de, weil die derzeitige Fehleransammlung und -Dauerhaftigkeit schlicht ein Witz ist.

Ich habe mich schon auf TNG umorientiert; da funktioniert jedenfalls alles dauerhaft und da ist morgen noch alles da, was man gestern noch eingegeben hat....

Aber wenn man den Stammbaum mit mehreren Leuten, entwickeln möchte, dann hat verwandt.de auch gute Seiten. Solange man nicht mit seinen Mitgestaltern entgegengesetzte Umsetzungswünsche hat.

Aber Ahnenblatt ist erste Wahl, so dachte ich das die Home-Edition-Funktion nur versteckt in AB brach liegt...

Das muss (in diesem Fall) die Home-Edition oder ein eigenes Tool können. Alles andere würde beim Import zu einer versteckten Informationsvernichtung führen (wenn man die Funktion nicht genau für diesen Zweck nutzt). Die Funktion hätte für Ahnenblatt und seine Nutzer schlicht keinen Nutzen.

Gerade die "Informationsvernichtung" habe ich bei AB gehofft, das sie vermieden wird.
Ich konnte die "spezifischen" Tags mit "_VW" nicht löschen und gegen normale ersetzen. So wäre aus "_VWOCCU" nur "OCCU" geworden. Aber die "unbekannten" Tags landeten gleich unter Anmerkungen. Schwups - schon kann kein Genealogie-Programm die OCCU-Daten mehr importieren.

Gruß


Olaf

[Marcus]

Gerade die "Informationsvernichtung" habe ich bei AB gehofft, das sie vermieden wird.

Informationsvernichtung in Ahnenblatt wäre, wenn sie eben nicht in die Anmerkungen übernommen werden! So sind sie an der einzig sinnvollen Stelle in Ahnenblatt abgelegt - anders wären sie in Ahnenblatt nicht zu gebrauchen.

Aber die "unbekannten" Tags landeten gleich unter Anmerkungen. Schwups - schon kann kein Genealogie-Programm die OCCU-Daten mehr importieren.

Es muss ja auch kein anderes Genealogieprogramm die OCCU-Daten mehr nutzen, da ich die Daten ja in Ahnenblatt importiert habe und dort bearbeiten will. Die Rücksichtnahme auf Strukturen anderer Programme, müssen die schon selbst erfüllen (bzw. die gewünschten Funktionen bereitstellen) - für Ahnenblatt macht das keinen Sinn! Auch wenn Du für Dich da einen netten Anwendungsfall hättest.
Marcus