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

[Talk-cz] RUIAN a inkrementální aktualizace

Vlákno 10.8. - 16.8.2014, počet zpráv: 4


10.8.2014 08:56:00 (#1)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
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

10.8.2014 09:49:18 (#2)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne Ne 10. srpna 2014 20:56:00, Petr Mor?vek [Xificurk] napsal(a): zobrazit citaci
> 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.
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
> * 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.
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
> > * 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.
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
> Na ostatn? tabulky jsem nekoukal, ale je dost mo?n?, ?e trp? podobn?m > probl?mem.
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

11.8.2014 10:14:52 (#3)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 10.8.2014 21:49, Petr Vejsada napsal(a): zobrazit citaci
> 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! > >> * 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. > > 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.
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

16.8.2014 10:42:50 (#4)
gravatar

Petr Souček

<soucekp at atlas.cz>
69
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
-----Original Message----- From: Vesel?, Ji?? Sent: Monday, August 11, 2014 10:31 AM To: Sou?ek, Petr; Form?nek, Ji?? Subject: FW: [Talk-cz] RUIAN a inkrement?ln? aktualizace Ahoj, v?me o tom? J. -----Original Message----- From: "Petr Mor?vek [Xificurk]" [mailto:petr at pada.cz] Sent: Monday, August 11, 2014 10:15 AM To: talk-cz at openstreetmap.org Subject: Re: [Talk-cz] RUIAN a inkrement?ln? aktualizace Dne 10.8.2014 21:49, Petr Vejsada napsal(a): zobrazit citaci
> 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! > >> * 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. 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 zobrazit citaci
> 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. zobrazit citaci
> > V dumpu z ?ervna by ov?em b?t m?l.
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 _______________________________________________ Talk-cz mailing list Talk-cz at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz

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