Es wäre wirklich sehr schön, wenn es für die Ortseingabe auch ein Feld für die GOV-Kennung gäbe. Dann wäre die Zuordnung eindeutig. Besonders wichtig ist dies beim Datenaustausch, beispielsweise beim Einspielen der Gedcom-Datei in eine Forscherdatenbank.

Auch das Feld "Region" ist ein sehr schwammiger Begriff. Ist da der Kreis, das Bundesland, der Verwaltungsbezirk oder was auch immer gemeint?

Viele Grüße, Charlotte

Das Feld Region ist rein informativ und wird für keine weitere Verwendung innerhalb des Stammbaums gebraucht, auch nicht zur Suche in der Landkarte. Mann kann also reinschreiben, was zu einem Ort sinnvoll als Ergänzung dazupaßt. Innerhalb Deutschlands je nach Zeitraum also Bundesland, altes Herrschaftsgebiet (z.B. Hessen-Homburg oder Sachsen-Meiningen-Hildburghausen oder Provinz Westpreußen), Landkreis - wie man Lust hat. In Frankreich entweder das Département oder die alte Regionalbezeichnung Provence, Bretagne oder ähnlich. In England die Grafschaft, in den USA den Bundesstaat - im alten Rom die Provinz, der Phantasie sind da keine Grenzen gesetzt. Wer faul ist, kann das Feld auch leer lassen ohne daß das Konsequenzen hätte. Streng genommen ist das Feld überflüssig und m.W. mit anderen Genealogie-Datenbanken auch nicht kompatibel.

Alles was man in das Feld Region schreibt, das wird dann auch exportiert und dadurch wird die Geocodierung beeinflusst, da jede Information im PLAC-tag ausgewertet wird.
Das gilt für Programme außerhalb von verwandt.de (vde).

Wie genau verwandt.de die PLAC-Daten auswertet, dazu hat sich vde nie ausführlich geäußert.
Man hätte aus diesen Informationen dann auch mal Gewissheit, warum der eine oder andere Eintrag nicht (mehr) funktioniert.

@ojay: Daß die Einträge im Feld Region außerhalb von vde verwertet werden, ist mir neu - bisher gab es im Forum dazu keine eindeutige Aussage. Erst einmal vielen Dank für diese Info. Was passiert nun, wenn der PLAC-tag nicht verwertbare Daten übermittelt bekommt - analog zu Google Earth sprich Landkarte bei veralteten Ortsbezeichnungen? Ignoriert der tag diese wie Google Earth es tut oder produziert so ein für den PLAC-tag "unleserlicher" Eintrag Folgefehler? Beispiel Adrianopolis Provinz Thrakien/Römisches Reich wird von Google Earth ignoriert (es kommt nur der Hinweis Ort nicht gefunden), Edirne/Türkei aber akzeptiert.
Ergänzend noch eine Anmerkung: Google Earth baut manchmal trotz korrekter Ortsnameneingabe in heutiger Schreibweise Mist, da wird ein in Lettland gelegener Ort nach Kalifornien verlegt, d.h über die Länderangabe Lettland bei gleichnamigem Ortsnamen setzt sich das Programm einfach hinweg und gibt nicht zu, daß es den lettischen Ort nicht kennt. Kann so etwas bei Angaben zur Region bei dem PLAC-tag beim Ein- und Auslesen auch passieren?
Spätestens dann wäre vde nämlich aufgefordert, zwecks Kompatibilität Vorgaben zu machen, was im Feld Region ein korrekter Eintrag ist und was nicht.

1.
Erstmal ist die GOV-Kennung ein "Projekt", das durch den ehrenamtlich arbeitenden Verein für Computergenealogie aufgebaut wurde, welches wohl nicht gedacht ist, das kommerziell noch kostenlos "weiter benutzt" werden sollte.
Zum zweiten exportiert verwandt.de die Geocodierung mit den tags (LATI/LONG) in dem GEDCOM-Export schon.
Das nun Gedbas von CompGen dies nicht (richtig) importiert, das liegt (ausnahmsweise) nicht an verwandt.de, sonst das beide Systeme unterschiedliche Gedcom-Standards verwenden bzw. manche tags unterschiedlich oder gar nicht importieren.
Wenn nun verwandt.de sich nun hinsetzt und noch ein "verwandt.de-spezifisches" Gedcom-tag kreiert und exportiert, dann weiß Gedbas noch immer nicht was es damit soll.

Ergo: Das einzige, was verwandt.de noch machen kann, das man die Geocodierung-tags (LATI/LONG) manuell im verwandt.de-System eintragen kann.

2.
Das PLAC-tag ist bei verwandt.de im Gedcom-Export folgendermaßen definiert:

Andere Programme (also alle ) verwenden folgendes Format

Wie Du die einzelnen Ebenen (Hierarchie) definierst, das bleibt Dir soweit überlassen, Hauptsache eine gleiche Anzahl von Ebenen ist vorhanden.
So ist das PLAC-tag in GEDCOM-Standart 5.5.1 definiert:
+1 PLAC
+2 FORM <PLACE_HIERARCHY>


Das ganze Import- und Export-Gedöns steht und fällt mit der Zusammenarbeit der einzelnen Programme.
Und man sieht ja wie verwandt.de sich an Standards hält.

@Pharao:
Das Feld Region wird, wie Du oben sehen kannst, auch in den verwandt.de-Export ausgegeben.
Das die Postleitzahl und die Straße im verwandt.de-Export noch dabei ist, das erschwert noch das ganze.
Wobei die Postleitzahl in das PLAC-tag überhaupt nicht hineingehört, denn es hat mittlerweile ein eigenes tag:


Zu "Adrianopolis Provinz Thrakien/Römisches Reich" oder sonstigen Konstrukten in den PLAC-tags:
IMHO was Google Maps nicht findet, das wird die sogenannte "Geocodierung" bei verwandt.de auch nicht finden. Denn dahinter wird sich nichts anderes verstecken.
Mit dem "Edirne/Türkei"-Beispiel wird es doch ganz deutlich:
Solange man sich an der aktuellen Hierarchie hält, dann klappt auch die Geocodierung, wie soll ein Programm heraus finden, was Du meinst? Besonders wenn die Ortsbezeichnung schon 1-2 Tage alt ist...
Zu Lettland oder sonstigen Ortsangaben kommt es auf den Einzelfall an, wie die Ortsbezeichnung schon vorhanden und beschrieben ist.

Das heißt also im Klartext: Solange man sich in den verschiedenen Genealogie-Programmen nicht auf übergreifend einheitliche Standards für das Ausfüllen (einschließlich Reihenfolge) der Felder und einen einheitlichen Inhalt der Felder geeinigt hat, wird es beim Export/Import von einem Programm ins andere immer irgendwelches Durcheinander geben. Und je mehr Zusatzfelder für irgendwelche Spezialwünsche eingerichtet werden, desto größer wird das Risiko, daß diese - und sei es nur aus Versehen - einem falschen tag zugeordnet werden und dann noch mehr Verwirrung stiften.
Nebenbei: Adrianopolis und Edirne sind ein und dieselbe Stadt, nur zu verschiedenen Zeiten.

Die Einigung zwischen manchen Genealogie-Programmen hat schon begonnen.
In wie weit verwandt.de sich genötigt werden füllt zeitnah ihren Gedcom-Export anzupassen, das wird abwarten müssen.
Der verwandt.de-Gedcom-Import ist ja nicht wichtig... wer braucht den noch?

Ich weiß, darum auch die Bemerkung mit "1-2 Tage"....

Ich habe in meiner Gedcom-Datei die zwei Kommas vor den Ortsnamen (wegen der fehlenden Straße und Postleitzahl) alle mühsam per Hand entfernt und danach die Datei erneut in GedBas importiert. Jetzt funktioniert die Ortssuche. Na schön, aber was ist, wenn ich viele neue Profile angelegt habe oder Profile ergänzt habe? Dann habe ich in einer neuen Gedcom-Datei die Kommas wieder drin und müßte sie erneut entfernen. Um diese Wahnsinnsarbeit zu vermeiden bleibt mir nur die Möglichkeit neue Eingaben doppelt vorzunehmen: einmal im Online-Stammbaum und einmal in der Gedcom-Datei. Na toll! Und dafür hat man eine Premiummitgliedschaft.

Grüße an Alle

Charlotte

Ich kann mir nur erklären das verwandt.de ein kommerzielles Unternehmen ist und nicht wirklich an der Genealogie und deren Arbeit irgendwie selbst ein Interesse verfolgt.
Sonst hätten sie auch von Anfang an die ganzen existenziellen Felder schon angeboten und nicht jede Funktion nach und nach erst eingerichtet. (wie z.B. Beerdigungsdatum, Quellen,...)
Auch hätten sie schon damals mal in den Gedcom-Standart einen Blick geworfen, dann wäre ihnen schon da aufgefallen, das der Export keine Straße und Postleitzahl enthält.
Aber Straße und Postleitzahl ist für Werbekunden eben interessanter

Ich hatte mal eine kleine Anleitung geschrieben, wie man den Gedcom-Export immer an andere Genealogieprogramme anpassen kann:
tutorium-hilfe-gedcom-export-und-seine-bearbeitung
Ob er in dieser Form für Gedbas passt, das weiß ich nicht.
Nur mit Suchen und Ersetzen mit Proton ist die Arbeit schon einfacher.
Wenn man alle Felder auch immer gleichmäßig ausfüllt, dann wird die Arbeit noch einfacher, denn es bleiben so dann die ersten beiden Kommata/Beistriche nur stehen, sobald man Ort,Region und Land immer ausfüllt.

Mir hat verwandt.de durch ihre Datenlöschung ja diese Export-Arbeit abgenommen, so das ich den Stammbaum nur noch mit TNG ergänze.

@Charlotte
Du kannst den Autor (Jesper Zedlitz) von Gedbas ja mal kontaktieren, ob dieser einen Rat hat, um die verwandt.de-Export-Daten schneller in Gedbas zu importieren. Dieser ist auch an dem Abgleich des Gedcom-Standards zwischen den Genealogie-Programmen beteiligt. - Darum besteht hier zumindest ein Weiterkommen auf der Agenda.
Wenn man Mitglied im Verein für Computergenealogie erhält man 4 mal im Jahr ein Heft. In dem aktuellen Heft 04/2009 steht eine Bericht über Gedbas4all, dieser sich mit einer Weiterentwicklung der Systeme bei CompGen beschäftigt.