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