Seite 1 von 2

Bug/Wunsch: Ortstexte kürzen

Verfasst: 29.12.2008, 11:37
von ojay
Hallo,

In der Funktion "Ortstexte kürzen" beim Tafeldruck werden, falls angegeben, die Postleitzahlen (PLZ) im Tafeldruck übernommen.

Ich sehe es als Bug an, da hier der Baum dadurch verunstaltet wird.

Es müsste also bis zum zweiten Komma gekürzt werden, denn bei einem Online-Genealogie-Prg. wird die PLZ auch exportiert.

Oder kann man das durch die Import-Wandelfunktion auch beheben? (=das PLZ-Löschen)

Danke

Verfasst: 29.12.2008, 13:50
von Marcus
Kannst Du mal einen Beispieleintrag geben, was genau im Ortsfeld steht? Dann können wir damit einen Wunsch oder eben eine Fehlermeldung machen. Derzeit klingt es für mich so, als würde nur das letzte Komma in einer Zeile berücksichtigt?
Marcus

Verfasst: 29.12.2008, 14:10
von Hugo
Guten Tag Ojay
Deinen Text hab ich jetzt schon 5 mal durchgelesen, kapiert hab ich ihn immer noch nicht :oops:

Im Laufe der Zeit hab ich schon viele Gedcom-Dateien gesehen, auch aus zig anderen Programmen
Nur Postleitzahlen sind mir da noch nie unter gekommen
(Auch wenn es dafür einen Gedcom-TAG gibt)

Wie auch, welche Postleitzahlen/Bezirksangaben hätten wir denn gerne
Die zB in Deutschland gerade gültigen, oder die vorherigen 4stelligen
oder die davorigen Bezirkangaben wie 20/2a

Um trotzdem Dein Problem lösen zu können
Könntest Du mir via PN einen Screenshot der Personen-Eingabemaske schicken?
Ferner bräuchte ich bitte mal einen kompletten Gedcom Datenblock einer Person, wo so eine von Dir erwähnte Plz drin ist

Gruß Hugo

PLZ im Ort-Tag bei Ahnenblatt / Gedcom-Import

Verfasst: 29.12.2008, 14:40
von ojay
Hier ist das mal erklärt...
http://www.verwandt.de/forum/post13529.html

verwandt.de-Format PLAC-Tag
Strasse,PLZ,Ort,Region,Land

Im konkreten Beispiel:
Gedcom-File:

0 @13225911@ INDI
1 SEX M
1 NAME xxx /xxxx/
2 GIVN xxx
2 SURN xxxx
1 RESI
2 PLAC ,46282,Dorsten,,Deutschland
1 BIRT
2 DATE xxx 19xx
2 PLAC ,46282,Dorsten,NRW,Deutschland
1 _VWCNT
2 _SVADR xxx@xxx.com
2 _TYPE EMAIL
1 _VWCNT
2 _SVADR xxx@xxx.com
2 _TYPE EMAIL
1 RIN 13225911_8
1 CHAN
2 DATE 30 MAI 2008
3 TIME 19:37:32
1 FAMC @49@
1 FAMS @469@

btw: "_VW***" sind verwandt.de-spezifische-Tags...

und zugehöriger Ahnenblatt-Screenshot:

Verfasst: 29.12.2008, 15:01
von Marcus
Der Export ist auch einfach schlecht. Sowohl das führende Komma (bei fehlender Straße), als auch das zwischen PLZ und Ort sollten einfach unterbleiben ...
Wir können das aber gerne in einen Wunsch packen - nur welcher Art bin ich mir bei der Darstellung grad recht unsicher. Wenn immer nur zwei Kommas beachtet werden, ist das eine sehr spezielle Option für den einen Export. Sobald dort der Export dann mal sinnvoller gestaltet wird, muss man Ahnenblatt wieder anpassen :? Wer schließlich aus diesem Export nur den Ort darstellen möchte, müsste die ersten beiden Infos ausfiltern lassen, die dritte darstellen und alle weiteren wieder unterdrücken.
Ich denke für solche Fälle wäre es sinnvoller sich eine noch flexiblere Importroutine zu wünschen, die hier einfach Informationen wegschneidet und in die Anmerkungen verbannt.
Marcus

Re: PLZ im Ort-Tag bei Ahnenblatt / Gedcom-Import

Verfasst: 29.12.2008, 15:10
von Hugo
Guten Tag Ojay
ojay hat geschrieben:2 PLAC ,46282,Dorsten,NRW,Deutschland
Jetzt gehts los, jeder kocht seine eigene Suppe
Da kann ich nur sagen: internationaler Datenaustausch ade

Seit wann gehören (Trenn)-Kommas nicht ans Wortende, sondern an den Anfang :shock:

Gruß Hugo

Ergänzung für Ojay
Du könntest aber vor dem Import mit einen Editor
2 PLAC ,
gegen
2 PLAC_ (statt _Underscore bitte Leerzeichen)
ersetzen lassen

Gruß Hugo

Verfasst: 29.12.2008, 15:56
von Marcus
Hugo das führende Komma kommt nur wenn - wie oben von mir beschrieben - die Straße fehlt ;) Die Ersetzung würde das Problem also nur eingrenzen und nicht lösen.
Marcus

Re: PLZ im Ort-Tag bei Ahnenblatt / Gedcom-Import

Verfasst: 29.12.2008, 16:13
von ojay
Hugo hat geschrieben: Ergänzung für Ojay
Du könntest aber vor dem Import mit einen Editor
2 PLAC ,
gegen
2 PLAC_ (statt _Underscore bitte Leerzeichen)
ersetzen lassen
Auch erzeugen diese Änderungen Fehlermeldungen.
Wenn jetzt gar noch jemand eine Strasse eingetragen hat, dann ist sowieso alles verloren.

Bei http://wiki-de.genealogy.net/GEDCOM-Test sieht man, das es andere Programme auch nicht erkennen können.

Ich werde solange der Export noch fehlerhaft ist und falls ich mal einen wichtigen Druck mache möchte, vorher über Suchen&Ersetzen mit einem Texteditor die Fehler beseitigen.

Verfasst: 29.12.2008, 16:53
von Marcus
Ich würde auf jeden Fall auch bitten, den Export so anzupassen, das man wählen kann:
a) alles in die Anmerkungen zu schreiben
b) die gewünschten Felder zusätzlich in den Ort - ohne Kommata! Oder ganz flexibel mit einem Komma an einer freiwählbaren Stelle - das wäre mal ein guter Export :)

So könnte dann jeder für sich entscheiden, was er im Ort gespeichert haben möchte, ohne auch nur 1bit an Informationen zu verlieren. Generell sind solche Eingriffe auf der Exportseite natürlich immer einfach zu lösen, als beim Import. Hier sind sie dort gar nötig.
Marcus

Gedcom-Regeln einhalten...

Verfasst: 30.12.2008, 13:03
von ojay
Das ist das Ergebnis, wenn sich ein Dienst nicht entscheiden kann, was er möchte.
Es soll eine Mischung aus Community (so viele Daten wie möglich) und der Genealogie sein.
Beides passt nur zusammen, wenn man sich sich an die Gedcom-Regeln hält und nichts neues hinzufügt.
Die Gedcom-Schnittstelle (besonders der Export-Teil) ist für so einen Dienst nicht wirklich von Interesse, denn durch den Export bekommen sie weder neue User (Kunden) noch bekommen sie Daten, die sie mal "nutzen" können.
Gar bedroht der Gedcom-Export den Dienst aus wirtschaftlicher Sicht.
Denn Andere - wie AB - können es jetzt schon besser. - und hier arbeitet (zwar schon mehrere Jahre...) nur ein Mann.
Marcus hat geschrieben:Ich würde auf jeden Fall auch bitten, den Export so anzupassen, das man wählen kann
Man kann nur "bitten" - denn wenn die wirtschaftlichen Lenker dies nicht einsehen... Die Programmierer können sicherlich auch richtig programmieren. :wink:
Marcus hat geschrieben:Generell sind solche Eingriffe auf der Exportseite natürlich immer einfach zu lösen, als beim Import. Hier sind sie dort gar nötig.
Die Gedcom-Ergebnisse sind als Insellösung ja richtig. Denn die wollen anscheinend nicht für andere (Programme) programmieren.
Warum auch? - der Gedcom-Import der (exportierten) Daten funktioniert ja!

Letztendlich haben die ja schon eigene Gedcom-Tags erfunden, damit der Community-Stammbaum irgendwie als Insellösung funktioniert. Das können die von mir aus auch bei der Postleitzahl (PLZ) machen... :roll:

Verfasst: 30.12.2008, 13:37
von Hugo
Guten Tag Ojay
Gestatte mir ein müdes grinsen :)
Gedcom wird nicht nur in der Genealogie eingesetzt

Gruß Hugo

Verfasst: 30.12.2008, 14:05
von Roger Paini
Hallo Hugo
Hugo hat geschrieben:Gedcom wird nicht nur in der Genealogie eingesetzt
*staun* :shock: *schluck*

Wo wird Gedcom denn sonst noch eingesetzt?

Gruss
Roger

Verfasst: 30.12.2008, 14:16
von Hugo
Guten Tag Roger
Rate mal, wer womit "über dem großen Teich" die Melderegister führt :lol:

Gruß Hugo

Verfasst: 30.12.2008, 15:20
von Roger Paini
Hallo Hugo

Klingt nach dem Land selber oder zumindest gewisse Staaten davon.
Liege ich richtig?

Gruss
Roger