[Talk-cz] FW: RUIAN a inkrementální aktualizace (VFR)

Vlákno 16.8. - 16.8.2014, počet zpráv: 1

Dobrý den, Ad SO 78153263) viz povídání v předchozím mailu Ad SO 78258294) 1) V ISKN byla evidována rozestavěná budova 2) v ISÚI byl 28.7.2014 zapsán číslovaný SO (78258294) 3) 29.7.2014 se SO dostal do změnového souboru. Vazba na budovu v ISKN zde chyběla správně, neboť rozestavěné budovy nejsou obsahem RÚIAN, tj. nepřebírá se do RÚIAN ani polygon (tato budova ho navíc nemá). 4) 29.7.2014 došlo k zápisu dokončené stavby (15680609010) v ISKN. Došlo k napojení této budovy na stavební objekt v ISÚI (vznikl na straně ISKN "můstek"). V RÚIAN došlo k doplnění BUD_ID a změně ID_TRANSAKCE. 5) a podle mě se měl 30.7.2014 vygenerovat změnový VFR a v něm se tato informace (SO 78258294) měla objevit. Vypadá to na chybu ve VFR, informoval jsem kolegy, kteří to budou řešit s dodavatelem. 6) 1.8.2014 se už ve stavovém objevila nová verze SO, doplněná o BUD_ID. Děkuji za report této chyby! Petr Souček

-----Original Message----- From: "Petr Morávek [Xificurk]" [mailto:petr na pada.cz] Sent: Sunday, August 10, 2014 8:56 PM To: OpenStreetMap Czech Republic Subject: [Talk-cz] RUIAN a inkrementální aktualizace 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> https://github.com/fordfrog/ruian2pgsql/issues/24 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140816/aba1ea22/attachment.html>

« zpět na výpis měsíce