Ahoj, mám nemilou zprávu pro vás, co pracujete s RUIAN (přes ruian2pgsql) a provádíte inkrementální aktualizace - "nefunguje" to. Petr Vejsada tu už na jaře psal, že má podezření, že nový import úplného dumpu RUIAN dává jiný výsledek než postupně aktualizovaná databáze přes změnové soubory. A já to bohužel teď musím potvrdit. A je to trochu komplikovanější. První problém byl v ruian2pgsql [1]. Původní algoritmus počítal s tím, že pokud dojde k nějaké změně objektu, tak se vždy zvýší "id transakce", což bohužel není pravda. Tento problém byl nedávno opraven... pokud používáte ruian2pgsql a importujete změnové soubory, tak silně doporučuju update na poslední dev verzi. Jenže i tak byly indikace, že není vše úplně v pořádku - a opravdu není. Mám tu dvě databáze: 1) Vznikla importem posledního úplného dump z konce července, konkrétně soubory 20140731_OB_*_UKSH.xml.gz a 20140731_ST_UKSH.xml.gz. 2) Vznikla importem úplného dumpu z konce června a pak importem všech změnových souborů z července, tj. soubory 20140630_OB_*_UKSH.xml.gz a 20140630_ST_UKSH.xml.gz a pak 26 souborů 201407*_ST_ZKSH.xml.gz. A když porovnám výsledek obou cest, tak se dá najít opravdu velké množství rozdílů. Konkrétně jsem se díval na stavební objekty. Některé SO jsou jen v (1), některé jen v (2), jiné jsou sice v obou databázích, ale jedna verze má neúplné údaje. Problematické SO jsem vystopoval do zdrojových dat a chyba je už tam. * SO 78153263 je v červencovém dumpu (20140731_OB_554791_UKSH.xml.gz), ale není v dumpu z června ani žádném změnovém souboru. * SO 78258294 je v červencovém dumpu (20140731_OB_576000_UKSH.xml.gz) - tam má IdTransakce=648617 a IsknBudovaId=15680609010. V červnovém dumpu není, ale je v jednom jediném změnovém souboru (20140728_ST_ZKSH.xml.gz), ale tam nemá nastaveno IsknBudovaId a IdTransakce=648063. ... Na ostatní tabulky jsem nekoukal, ale je dost možné, že trpí podobným problémem. -- Informaci píšu primárně sem do talk-cz, protože to tu sledují jak konzumenti dat, tak i zástupci ČÚZK. Chtěl bych poprosit pana Součka, jestli by mě (nás) nasměroval, kam/jak/jestli tento problém reportovat, případně jaké další detaily by bylo vhodné dodat. -- Zdraví, Petr Morávek aka Xificurk [1] https://github.com/fordfrog/ruian2pgsql/issues/24

Ahoj, Dne Ne 10. srpna 2014 20:56:00, Petr Morávek [Xificurk] napsal(a): zobrazit citaci jestli chápu vše správně, tak nelze říci "nefunguje TO", pokud TO jsou inkrementální aktualizace. Obdobně by se za TO dalo dosadit, že nefunguje nahrání celku ;-). Mám schema, vzniklé z dat ke dni 30.4. plus aktualizace. Od začátku těch aktualizací tam mám ten patch, co ignoruje čísla transakcí, tedy *ignoruje*, není tam >=, jak je asi v poslední -dev, viz debata na Githubu. To jen pro pořádek. Ač není pravděpodobné, že by se čísla transakcí někdy dekrementovala, vyloučit to asi nemůžeme! zobrazit citaci select deleted,id_trans_ruian,definicni_bod is not NULL as definicni_bod,hranice is not NULL as hranice,plati_od,item_timestamp from ruian.rn_stavebni_objekt where kod=78153263; deleted | id_trans_ruian | definicni_bod | hranice | plati_od | item_timestamp ---------+----------------+---------------+---------+------------+---------------------------- f | 627026 | t | f | 20.06.2014 | 22.06.2014 11:38:58.947812 je tedy ve změnovém souboru z průběhu června. Nahráno 22.6., takže asi soubor z 21.6., ale nevím jistě. Nenahrávám každý den, jen skoro každý den. V dumpu z června by ovšem být měl. zobrazit citaci Toto souhlasí, přesně toto mám v DB včetně absence budova_id Z toho nám vyplývá, že chyby jsou v obojím - jak v dumpech, tak ve změnových souborech :( zobrazit citaci Vzpomínám si, že jsme si srovnávali count(*),count(definicni_bod) a kde je relevantní, tak i count(hranice). U tabulky adres jsme se, kupodivu, shodli :-). Ostatní si nepamatuji. -- Petr

Dne 10.8.2014 21:49, Petr Vejsada napsal(a): zobrazit citaci Tak tohle mě vážně nenapadlo... dohledal jsem to ve změnovém souboru z 20.6. a obsah do puntíku sedí s tím, co je v červencovém dumpu. Ale v červnu fakt nebyl. Takže chyby jsou vážně v obojím, což opravdu není dobré :/ Petr

Dobrý den, včera jsem o tom diskutoval s kolegou. A dnes jsem si tento konkrétní případ analyzoval a situace je následující. 1) 20.6.2014 došlo k zápisu SO 78153263 do ISÚI. Jedná se o SO bez čísla (typ 3) a byl zapsán na parcelu (ID 41994826010) z potvrzeného GP (tj. tzv. G parcela), která není v RÚIAN 2) 21.6.2014 se tento SO standardně dostal do změnového VFR, neboť ten se generuje za stát a dostanou se do něj všechny SO 3) 1.7.2014 se tento SO do stavového VFR nedostal, neboť SO se rozdělují do VFR po obcích (pro číslované dle části obce, pro nečíslované dle parcely a příslušnosti do k.ú. => obce). V tomto případě se do obce nezařadí, neboť by se měl rozdělit dle parcely, ale zatím v RÚIAN neexistuje (zatím je pouze v budoucnosti, ve vrstvě potvrzených GP v ISKN). 4) 28.7.2014 došlo k zápisu stavby v KN a tím pádem se parcela (ID 41994826010) dostala do přítomnosti ISKN a také do RÚIAN. 5) 1.8.2014 došlo standardně k vygenerování stavového VFR, kde už se SO zařadil dle parcely do příslušné obce Z toho mi vyplývá, že takových případů je relativně hodně. Jsou to všechny nově zapisované SO bez čísla, která jsou zapsána na parcelu z potvrzeného GP (a když o tom přemýšlím, tak to samé platí i pro parcelu, která je již pouze v minulosti - např. pokud dojde k přečíslování parcel v důsledku obnovy operátu a tím pádem "k ustřelení" identifikační parcely v ISÚI). Jestli dobře koukám, tak se jedná o cca 28,5 tisíc SO. Na základě výše uvedeného si myslím, že bychom se tím měli zabývat a zapsat požadavek na úpravu generování VFR. A to tak, aby se tyto SO dostali do VFR. Tohle bohužel musíme řešit s naším dodavatelem, takže to nebude obratem. Rozhodně díky za report tohoto problému, o jeho řešení Vás budeme informovat. Petr Souček