GENEALOGIE

Přidal jsem do nové verze Vámi uvedený formát, vyzkoušejte jej i ten odkaz co Vám předtím nešel. Mně to šlo vše.
Odkaz na novou verzi: http://dxe.jecool.net/downloads/aplinkconverter.1.8

Na úvodní stranu vlákna ji přidám, pokud se nevyskytnou nějaké zjevné chyby.

Převod toho nového formátu super, funkční.

Bohužel ten jeden link stále hlasí tu chybu co minule

Odkaz nepřeveden: U matriky sig. 16482 jsou značeny korekce, ale databáze starých snímků matriku neobsahuje - http://actapublica.eu/matriky/brno/proh ... strana=228
Převádění odkazů v souborech dokončeno.

Zkuste si znovu natáhnout zdrojové soubory pro převody tak, že ty staré smažete a spustíte aplikaci, která si je stáhne znovu. Možná je chyba tam. Jedná se o soubory:

• prevodni-tabulka.csv,
• snimky_castecne.zip,
• a snimky.zip

Soubory se nachází tam, kde je umístěný soubor s aplikací.

Matrika sig. 16482 by měla jít normálně převádět. Konvertor kolegy chipsi
http://apkonv.chipsi.cz/
s tím nemá problém (tedy převádí jen klasický formát odkazů).
S těmi seznamy snímků nových a starých matrik pozor - v názvech nejsou signatury, ale ID v databází MZA - to je to číslo, které se ukazuje (a ukazovalo) v odkazu. To není signatura.

No koukal jsem se na soubor 07298.lst z archivu snimky.zip a na řádku 108 a 110 jsou uvedeny identické názvy snímků ("216000010-000253-003380-000000-016482-000000-00-B07465-01090.jp2"). To nějak nechápu.
Podle toho souboru by pak:
snímek 107 byl převeden na 01070.jp2 (to se zdá být v pořádku)
snímek 108 byl převeden na 01090.jp2
snímek 109 byl převeden na 01080.jp2
a snímek 110 byl převeden opět na 01090.jp2

To mi nedává smysl.

V tabulce prevodni-tabulka.csv je indikována korekce -1. Čili bych z toho chápal, že nějaký snímek vypadl. V tomto případě tam chybí číslo 108. Proč jsou ale ty nové snímky uvedené v takovém pořadí a ještě navíc se jeden opakuje to mi prosím vysvětlete.

greghouse píše:Zkuste si znovu natáhnout zdrojové soubory pro převody tak, že ty staré smažete a spustíte aplikaci, která si je stáhne znovu. Možná je chyba tam. Jedná se o soubory:

• prevodni-tabulka.csv,
• snimky_castecne.zip,
• a snimky.zip

Soubory se nachází tam, kde je umístěný soubor s aplikací.

Pomohlo, díky.

greghouse:
ve staré verzi byly na následujících snímcích následující folia:

Kód: Vybrat vše

snímek |  folia
 107   | 210/211
 108   | 214/215
 109   | 212/213
 110   | 214/215 (opět)

Zkuste srovnat s tím, co vrátí převodník. Mělo by to být správně.

Jaký výstup chcete takový bude. Verzi 1.8 jsem teda přidal na hlavní stránku a mělo by to tedy převádět i ty dotazované odkazy.

Tak jsem se dnes odhodlal k tomu, že si zkusím převést odkazy v MH.
Zkrátím to, nejsem úplně nadšen chováním MH. Jediný způsob, jak odkazy převést je export GEDCOM, převod, impord GEDCOM. Jenže - když importuju do stávajícího projektu, tak MH otrocky přidá všechny osoby duplicitně. Sice to hezky okomentuje, ale nenabídne nějakou aktualizaci dat, nic.
Navíc jsou tam další drobnosti, které se mi úplně nelíbí.
Takže moje otázka zní - bylo by reálné ten převodník přiohnout tak, aby dokázal vyměnit odkazy v SQLite databázi - tedy přímo v tom originálním MH souboru, se kterým pracuje MH FTB? Páč kdyby to šlo, byla by to naprosto dokonalé.

Těžko říct, nemám zdání jakou to má podobu. MH nepoužívám. Můžete poskytnout testovací příklad?

viz SZ

Tak jsem se konečně odhodlal k tomu vyexportovat všechny mé stromy z MH, převést odkazy a znovu je naimportovat. Všiml jsem si, že mi to několik odkazů nepřevedlo. Jedná se o odkazy v GED souboru, které jsou v dlouhých textových polích (TEXT), která jsou rozdělena a mají pokračování v CONC. Tady je příklad:

...
3 TEXT <p>svatba -&nbsp;<a href="https://www.mza.cz/actapublica/matrika/detail/10182?image=216000010-000253-003377-000000-012320-000000-00-B02355-00480.jp2">https://www.mza.cz/actapublica/matrika/detail/10182?image=216000010-000253-003377-000000-012320-000000-00-B02355-00480.jp2</a></p>
<p>narozen -&nbsp;<a href="http://actapu
4 CONC blica.eu/matriky/brno/prohlizec/9501/?strana=262">https://www.mza.cz/actapublica/matrika/detail/9425?image=216000010-000253-003377-000000-011365-000000-00-B02976-02620.jp2</a></p>
...

Takové problémy (rozdělování polí kvůli délce) bych čekal v 80. letech minulého století, ale ne teď. Ten GED formát je prostě strašný

Kód: Vybrat vše

Long values can be broken into shorter GEDCOM lines by using a subordinate CONC or CONT
tag.

- THE GEDCOM STANDARD Release 5.5.1 (str. 10)

Jak sympatické od nich. Předpokládám, že bude v našem zájmu toto zachovat.

Ekharon píše:Tak jsem se konečně odhodlal k tomu vyexportovat všechny mé stromy z MH, převést odkazy a znovu je naimportovat. Všiml jsem si, že mi to několik odkazů nepřevedlo. Jedná se o odkazy v GED souboru, které jsou v dlouhých textových polích (TEXT), která jsou rozdělena a mají pokračování v CONC. Tady je příklad:

...
3 TEXT <p>svatba -&nbsp;<a href="https://www.mza.cz/actapublica/matrika/detail/10182?image=216000010-000253-003377-000000-012320-000000-00-B02355-00480.jp2">https://www.mza.cz/actapublica/matrika/detail/10182?image=216000010-000253-003377-000000-012320-000000-00-B02355-00480.jp2</a></p>
<p>narozen -&nbsp;<a href="http://actapu
4 CONC blica.eu/matriky/brno/prohlizec/9501/?strana=262">https://www.mza.cz/actapublica/matrika/detail/9425?image=216000010-000253-003377-000000-011365-000000-00-B02976-02620.jp2</a></p>
...

Takové problémy (rozdělování polí kvůli délce) bych čekal v 80. letech minulého století, ale ne teď. Ten GED formát je prostě strašný

Pokusil jsem se ten problém vyřešit v nové verzi 1.9. Prosím, vyzkoušejte, zda se to chová podle očekávání a dejte vědět. Mělo by to ty CONC tagy dočasně odebrat, převést odkazy a pak je na cca stejné místo vrátit.

Stáhnout aplikaci ( verze 1.9 )

Mě nejvíc vytáčí vlastnost MH, kdy při exportu do GEDCOM vyexportuje pořadí záznamů úplně zmateně. Takže po zpětném reimportu se změní ID u všech osob v rodokmenu. Netuším, co to udělá s různými vazbami, které si někdo jiný udělal do mého rodokmenu.