[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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RUIAN a inkrementální aktualizace
Ahoj, Dne Ne 10. srpna 2014 20:56:00, Petr Morávek [Xificurk] napsal(a): 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! * 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. * 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 :( 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Dokončení importu adres
Ahoj, zbývá nám necelé jedno procento adres, přičemž půlka toho procenta je problematická. Jedná se o obce: okres Praha-východ: Jevany Kozojedy Stříbrná Skalice Vyžlovka okres Břeclav: Mikulov Břeclav U všech, s výjimkou Břeclavi, jde o značný podíl dvojitých (trojitých, ...) adres typu číslo 35 a 5035. Nechce se mi vědomě toto nahrávat do OSM, i když v minulosti byly nahrány i obce s větším podílem tohoto jevu Můj dotaz také směruje na pana Součka ;-), zda zjistil, co je to vlastně za jev, proč to takto je a zda se dá očekávat oprava a kdy, případně na koho se obrátit či zda je nějaké pravidlo, podle kterého bychom mohli tyto adresy odstranit. Tím myslím třeba v těch dvojicích vždy odstranit to velké číslo, tedy 5035 a 35 ponechat? Smazat adresní místo, které přísluší nekompletnímu SO (tedy SO, který má vyplněné jen minimální množství údajů)? Obec Břeclav je trošku jiná. Také se jedná o duplicitu adres, ale týká se hlavně orientačních čísel. Jeden dům má orientační číslo třeba 3 a zároveň 124 nebo jsou tam doby, které mají orientační čísla 2 3, 3 4, 5 6 nebo 2 4, 4 6, 6 8 atd. V naprosté většině případů má geometrii jen jedna z těchto adres. Vzniká tak z toho domněnka, že obsluha příslušného programu na stavebních úřadech čí kde, si myslí, že schováním geometrie adresa neexistuje. Druhá věc - myslím si, že všechny 2/3 okresů by se měly projet ještě jednou, a to pouze se zapnutou funkcí mazání stylem co není v RÚIAN, to přijde pryč Toto se totiž dělá až od nové verze bota, kterým byla zpracována poslední třetina adres a 2/3 by se tedy měly ještě jednou prohlédnout a promazat. Stále namátkově kontroluji, co se chytal bot smazat a v naprosté většině případů to byla místa, kde je na ortofoto vidět zbořeniště či i z leteckého pohledu je patrné, že střechou do něho už roky zatéká a fakticky je to vrak ;-). S poslední informací o chybách ve výměnném formátu bych s tím ještě počkal -- Petr, p...@propsychology.cz p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Návod: jak natlačit lesy do zákoutí v LPIS (ContourMerge plugin)
Ahoj, Při hledání možností, jak řešit problém v předmětu jsem procházel seznam pluginů a narazil na CountourMerge plugin [1]. Ten už mám sice dlouho nainstalovaný, ale až dnes jsem se na něj podíval podrobněji a zjistil jak se s ním vlastně pracuje. Není to nic složitého, jsou potřeba jen dva segmenty, se kterými plugin manipuluje. Velmi dobře to funguje u poloostrovů tvořených jednou cestou. Pokud je tam těch cest více, tak to taky jde, ale je to větší piplačka - je potřeba pracovat s každou cestou zvlášť. Udělal jsem k tomu obrázkový návod a protože se mi nevešel do emailu, najdete jej tady: http://osm.kyralovi.cz/navody/ContourMerge_plugin.html Snad se to bude někomu hodit. Marián [1] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/ContourMerge ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
