[Talk-cz] Aktualizace RUIAN

Zdravim, na zaklade vcerejsiho zjisteni jsem se pustil do kompletne noveho nahrani dat z RUIAN. To znamena, ze vrstvy z tile.poloha.net budou fungovat az do nahrani omezene. Co je vyrenderovane, to se zobrazi, co vyrenderovane neni, tak pak zalezi na tom, zda konkretni obec uz je nahrana. Bohuzel to nahrani do DB trva dlouho. -- Petr

Dne 2.5.2014 10:50, Petr Vejsada napsal(a): zobrazit citaci

> Zdravim, > > na zaklade vcerejsiho zjisteni jsem se pustil do kompletne noveho nahrani dat > z RUIAN. To znamena, ze vrstvy z tile.poloha.net budou fungovat az do nahrani > omezene. Co je vyrenderovane, to se zobrazi, co vyrenderovane neni, tak pak > zalezi na tom, zda konkretni obec uz je nahrana. Bohuzel to nahrani do DB > trva dlouho. >

Ahoj, na jak dlouho to vidíš? On totiž nefunguje ani PointInfo, tak ať vím, co si mám naplánovat. Marián

On Fri, May 02, 2014 at 02:36:07PM +0200, Marián Kyral wrote: zobrazit citaci

> Dne 2.5.2014 10:50, Petr Vejsada napsal(a): > > Zdravim, > > > > na zaklade vcerejsiho zjisteni jsem se pustil do kompletne noveho nahrani dat > > z RUIAN. To znamena, ze vrstvy z tile.poloha.net budou fungovat az do nahrani > > omezene. Co je vyrenderovane, to se zobrazi, co vyrenderovane neni, tak pak > > zalezi na tom, zda konkretni obec uz je nahrana. Bohuzel to nahrani do DB > > trva dlouho. > > > > Ahoj, > na jak dlouho to vidíš? On totiž nefunguje ani PointInfo, tak ať vím, co > si mám naplánovat.

Zrovna jsem ti psal do mailu - pointinfo by mělo fungovat, ovšem jen na místech, kde už jsou data nahraná. Nahrávám od rána znovu, jsem v necelé půlce. Myslím, že do půlnoci by mělo vše být. V Praze je vadný polygon, čeká mě ruční editace řádku dlouhého 888 MB :-\. Nechápu, jak může být v datech z ČÚZK vadný polygon. -- Petr

Dne 2.5.2014 14:59, Petr Vejsada napsal(a): zobrazit citaci

> Zrovna jsem ti psal do mailu - pointinfo by mělo fungovat, ovšem jen na místech, > kde už jsou data nahraná. Nahrávám od rána znovu, jsem v necelé půlce. Myslím, > že do půlnoci by mělo vše být. V Praze je vadný polygon, čeká mě ruční editace > řádku dlouhého 888 MB :-\. Nechápu, jak může být v datech z ČÚZK vadný polygon.

Nevím, co se změnilo, ale poslední cca 3 měsíce se to stává nepříjemně často. Dřív jsem na tenhle problém nenarážel. Petr Morávek aka Xificurk

Dne 2.5.2014 14:59, Petr Vejsada napsal(a): zobrazit citaci

> On Fri, May 02, 2014 at 02:36:07PM +0200, Marián Kyral wrote: >> Dne 2.5.2014 10:50, Petr Vejsada napsal(a): >>> Zdravim, >>> >>> na zaklade vcerejsiho zjisteni jsem se pustil do kompletne noveho nahrani dat >>> z RUIAN. To znamena, ze vrstvy z tile.poloha.net budou fungovat az do nahrani >>> omezene. Co je vyrenderovane, to se zobrazi, co vyrenderovane neni, tak pak >>> zalezi na tom, zda konkretni obec uz je nahrana. Bohuzel to nahrani do DB >>> trva dlouho. >>> >> Ahoj, >> na jak dlouho to vidíš? On totiž nefunguje ani PointInfo, tak ať vím, co >> si mám naplánovat. > > Zrovna jsem ti psal do mailu - pointinfo by mělo fungovat, ovšem jen na místech, > kde už jsou data nahraná. Nahrávám od rána znovu, jsem v necelé půlce. Myslím, > že do půlnoci by mělo vše být. V Praze je vadný polygon, čeká mě ruční editace > řádku dlouhého 888 MB :-\. Nechápu, jak může být v datech z ČÚZK vadný polygon.

Právě, že jsem teď chtěl editovat, kde data ještě nejsou ;-) Ad XML) Co takhle si jej přeformátovat? Třeba pomocí XMLStarlet ( http://xmlstar.sourceforge.net ) Marián zobrazit citaci

> -- > Petr > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

Dne 2.5.2014 15:19, Marián Kyral napsal(a): zobrazit citaci

> Ad XML) > Co takhle si jej přeformátovat? Třeba pomocí XMLStarlet ( > http://xmlstar.sourceforge.net ) > > Marián

Na to stačí i libxml2: xmllint --format file.xml Ale ty soubory jsou pořád (celkově) dost velké, obzvláště v Praze :/ Petr

Dne 2.5.2014 15:24, "Petr Morávek [Xificurk]" napsal(a): zobrazit citaci

> Dne 2.5.2014 15:19, Marián Kyral napsal(a): >> Ad XML) >> Co takhle si jej přeformátovat? Třeba pomocí XMLStarlet ( >> http://xmlstar.sourceforge.net ) >> >> Marián > Na to stačí i libxml2: > xmllint --format file.xml > > Ale ty soubory jsou pořád (celkově) dost velké, obzvláště v Praze :/ > > Petr >

Však to byl jen příklad. Xmlstarlet umí navíc to xml prohledávat, editovat, transformovat i validovat. A stejně je rozdíl, jestli to je 800MB na jednom řádku nebo 800MB rozdělených na milión řádků. Marián

Dne Pá 2. května 2014 15:24:05, Petr Morávek [Xificurk] napsal(a): zobrazit citaci

> Na to stačí i libxml2: > xmllint --format file.xml > > Ale ty soubory jsou pořád (celkově) dost velké, obzvláště v Praze :/

Jo, to je dobrý, dík. Tak s Prahou konečně dobojováno, vadný polygon u ZSJ 306045 Za Hornoměcholupskou a prázdný polygon u ZSJ 132021 - Horní Měcholupy-sever. Začnu rozesílat objednaná data na import adres. -- Petr

Ty chyby jsou tam myslím od března, už jsem to hlásil na podpora na cuzk.cz. MK "Petr Vejsada" píše v diskusním příspěvku news:5233309.6ma79d05rp na mrnous... Dne Pá 2. května 2014 15:24:05, Petr Morávek [Xificurk] napsal(a): zobrazit citaci

> Na to stačí i libxml2: > xmllint --format file.xml > > Ale ty soubory jsou pořád (celkově) dost velké, obzvláště v Praze :/

Jo, to je dobrý, dík. Tak s Prahou konečně dobojováno, vadný polygon u ZSJ 306045 Za Hornoměcholupskou a prázdný polygon u ZSJ 132021 - Horní Měcholupy-sever. Začnu rozesílat objednaná data na import adres. -- Petr

Zdravím, Dne Út 13. května 2014 20:58:37, Martin Kokes napsal(a): zobrazit citaci

> Ty chyby jsou tam myslím od března, už jsem to hlásil na podpora na cuzk.cz.

jelikož zpracovávám změnové soubory takřka denně, tak jsem si toho všiml asi brzy. 28. března jsem posílal na podpora na cuzk.cz tento mail: ******************* Dobrý den, pro projekt Openstreetmap používáme jako jeden ze zdrojů dat RUIAN. V poslední době dochází k neobvyklostem ve změnových souborech. Konkrétně se jedná o nevalidní polygony a chybějící identifikaci obce u katastrálního území. Příklady: Změnový soubor 20140324_ST_ZKSH.xml.gz obsahuje, podle mého názoru, nevalidní polygon u ZSJ 306045 - polygon je uzavřený a na jeho konci ještě přebývá "ocásek" v podobě jednoho bodu navíc Změnový soubor 20140327_ST_ZKSH.xml.gz obsahuje katastrální území 920681 a katastrální území 929930, ale u obou chybí vazba na obec (chybí kód obce). Je to takto v pořádku? Může být katastrální území, které nenáleží žádné obci? Pokud jde opravdu o chyby, přimlouval bych se za to, aby změnový soubor byl rozdělený na řádky alespoň elementy <vf:xxxxx></vf:xxxxx>. Řádek, dlouhý 67MB se opravdu ručně opravuje dost nepohodlně. Děkuji předem za vyjádření. -- Zdraví Petr Vejsada ******************* Odpověď žádná, polygon neopraven, ta vazba na obec opravena byla i bez mého upozornění. -- Petr

Nojo, paní Landová z podpory bývá dost skoupá na vyjádření, většinou něco někam forwardne a děj se vůle boží. Pak možná forwardne zpátky nějakou odpověď. :-) Většinou pomůže oslovení někoho dalšího, který je více vstřícný, třeba tu vidím, že se zapojil Petr Souček. Můžete zkusit i Pavel Šidlichovský, který vede správu ZABAGEDu (a tím pádem asi i adresní místa). E-maily snadno odvodíte jmeno.prijmeni. MK "Petr Vejsada" píše v diskusním příspěvku news:2002810.zTFi1LYSpi na mrnous... Zdravím, Dne Út 13. května 2014 20:58:37, Martin Kokes napsal(a): zobrazit citaci

> Ty chyby jsou tam myslím od března, už jsem to hlásil na podpora na cuzk.cz.

jelikož zpracovávám změnové soubory takřka denně, tak jsem si toho všiml asi brzy. 28. března jsem posílal na podpora na cuzk.cz tento mail: ******************* Dobrý den, pro projekt Openstreetmap používáme jako jeden ze zdrojů dat RUIAN. V poslední době dochází k neobvyklostem ve změnových souborech. Konkrétně se jedná o nevalidní polygony a chybějící identifikaci obce u katastrálního území. Příklady: Změnový soubor 20140324_ST_ZKSH.xml.gz obsahuje, podle mého názoru, nevalidní polygon u ZSJ 306045 - polygon je uzavřený a na jeho konci ještě přebývá "ocásek" v podobě jednoho bodu navíc Změnový soubor 20140327_ST_ZKSH.xml.gz obsahuje katastrální území 920681 a katastrální území 929930, ale u obou chybí vazba na obec (chybí kód obce). Je to takto v pořádku? Může být katastrální území, které nenáleží žádné obci? Pokud jde opravdu o chyby, přimlouval bych se za to, aby změnový soubor byl rozdělený na řádky alespoň elementy <vf:xxxxx></vf:xxxxx>. Řádek, dlouhý 67MB se opravdu ručně opravuje dost nepohodlně. Děkuji předem za vyjádření. -- Zdraví Petr Vejsada ******************* Odpověď žádná, polygon neopraven, ta vazba na obec opravena byla i bez mého upozornění. -- Petr

Dobrý den, pokusím se zareagovat na níže uvedený dotaz. Většinou se ke mně dotazy na VFR z podpory ČÚZK dostávají a snažím se na ně (ve spolupráci s kolegy) odpovídat. Tenhle jsem ovšem nezaznamenal. Adresní místa jsou součástí RÚIAN, takže je možné kontaktovat kolegu Ing. Jiřího Formánka - ten určitě poradí také, případně předá kompetentnímu kolegovi. A nyní k diskutovaným problémům: 1) nevalidní polygony - o tomto problému víme. Jedná se o chybu v aplikaci, kterou řešíme s naším dodavatelem. Doufám, že se nám podaří novou verzi nasadit co nejdříve. 2) katastrální území bez obce - to se stát může. Jedná se o dočasné řešení, které souvisí s procesem vzniku katastrálního území (v současné době probíhá vytváření nových k.ú. v souvislosti s optimalizacemi vojenských újezdů v ČR). Nejdříve se vytvoří prázdná obálka k.ú. v ISKN (1), následně se v ISÚI přiřadí k.ú. vazba na obec (2) a nakonec v ISKN proběhlo naplnění k.ú. parcelami (3). Pokud body (1) a (2) neproběhnou v rámci jednoho dne, tak se v datech RÚIAN objeví k.ú. bez vazby na obec. My na ČÚZK se o tento postup snažíme, ale v některých případech se to nepovede. 3) XML na jednom řádku - pokusíme se zajistit. My některá XML už takto poskytujeme - viz základní sada RÚIAN, např. soubor http://vdp.cuzk.cz/vymenny_format/soucasna/20140430_OB_550671_UZSZ.xml.gz . Tyto soubory totiž vytváříme pomocí XSLT transformace z kompletní datové sady vlastními prostředky. Kompletní datovou sadu vytváří aplikace - tudíž budeme muset řešit s naším dodavatelem jako změnový požadavek, abychom sjednotili poskytování našich dat. Pěkný den přeje Petr Souček

-----Original Message----- From: Martin Kokes [mailto:shr3k na typo3-hosting.com] Sent: Tuesday, May 13, 2014 9:25 PM To: talk-cz na openstreetmap.org Subject: Re: [Talk-cz] Aktualizace RUIAN Nojo, paní Landová z podpory bývá dost skoupá na vyjádření, většinou něco někam forwardne a děj se vůle boží. Pak možná forwardne zpátky nějakou odpověď. :-) Většinou pomůže oslovení někoho dalšího, který je více vstřícný, třeba tu vidím, že se zapojil Petr Souček. Můžete zkusit i Pavel Šidlichovský, který vede správu ZABAGEDu (a tím pádem asi i adresní místa). E-maily snadno odvodíte jmeno.prijmeni. MK "Petr Vejsada" píše v diskusním příspěvku news:2002810.zTFi1LYSpi na mrnous... Zdravím, Dne Út 13. května 2014 20:58:37, Martin Kokes napsal(a): zobrazit citaci

> Ty chyby jsou tam myslím od března, už jsem to hlásil na podpora na cuzk.cz.

jelikož zpracovávám změnové soubory takřka denně, tak jsem si toho všiml asi brzy. 28. března jsem posílal na podpora na cuzk.cz tento mail: ******************* Dobrý den, pro projekt Openstreetmap používáme jako jeden ze zdrojů dat RUIAN. V poslední době dochází k neobvyklostem ve změnových souborech. Konkrétně se jedná o nevalidní polygony a chybějící identifikaci obce u katastrálního území. Příklady: Změnový soubor 20140324_ST_ZKSH.xml.gz obsahuje, podle mého názoru, nevalidní polygon u ZSJ 306045 - polygon je uzavřený a na jeho konci ještě přebývá "ocásek" v podobě jednoho bodu navíc Změnový soubor 20140327_ST_ZKSH.xml.gz obsahuje katastrální území 920681 a katastrální území 929930, ale u obou chybí vazba na obec (chybí kód obce). Je to takto v pořádku? Může být katastrální území, které nenáleží žádné obci? Pokud jde opravdu o chyby, přimlouval bych se za to, aby změnový soubor byl rozdělený na řádky alespoň elementy <vf:xxxxx></vf:xxxxx>. Řádek, dlouhý 67MB se opravdu ručně opravuje dost nepohodlně. Děkuji předem za vyjádření. -- Zdraví Petr Vejsada ******************* Odpověď žádná, polygon neopraven, ta vazba na obec opravena byla i bez mého upozornění. -- Petr